Kde a jak ošetřit chyby? Vyjimky a nebo if?
- radik
- Člen | 21
Cau,
kde nejlip v Nette osetrovat chyby? Dam priklad, ze treba nenajdu uzivatele
v DB, tak jak to udelat spravne?
- mam v presenteru zkontrolovat zda me model nevratil NULL a podle toho napriklad vypsat flashmessage, ze uzivatel neexistuje?
- ma me model hodit vyjimku a v presenteru jen zobrazit hlaseni vyjimky do flashmessage?
Pripadne kdyz jsou to jiny situace tak kontrolovat i v presenteru + v modelu, ktery hodi vyjimku a osetrit to vzdy tak, aby vyjimka byla az nejpolednejsi moznost, ktera by nemela nikdy nastat?
- radik
- Člen | 21
Nebo pokud budu chtit vlozit uzivatele do databaze a pouziji doctrine.
Kontrolovat v presenteru, ze uzivatel ma povoleny znaky (nebo jen cekat na
vyjimku)?
Kontrolovat v modelu (nebo cekat na vyjimku z doctrine ze je nepovoleny
znak)?
Kontrolovat v entite (nebo cekat na vyjimku z doctrine)?
Kontrolovat vsude, aby nebylo mozny vyjimku vubec vyhodit?
- JZechy
- Člen | 161
Na zpracování databázových dat používám v modelu Service, kde pracuji s repositořema a vracím entity, případně něco jiného (bool, int, … Záleží, co metoda dělá).
Samozřejmě kolikrát jsou i složitější Service, kde se musí nějaké hodnoty jakkoli ověřovat či případně kontrolovat stav ukládané entity, zda se tato metoda může provést a v případě chyby se mi v tomto případě jeví výjimka jako nejlepší případ.
A třeba konkrétně u uživatele, ověření emailu a uživatelského jména jsem si přesunul do Service a pokud již jméno nebo mail existuje, vracím výjimku.
V presenteru nebo komponentě pak už volám požadovanou service a většinou ze service volám jednu/dvě metody, kde už se data do DB nějak zpracují.
A samozřejmě pak i pro testování je Service výhoda, protože různé logiky ukládání do databáze otestuješ velice snadno, a když sesmolíš něco, co se může na více místech opakovat, je vhodné to mít kdekoli jinde a né přímo v té komponentě nebo presenteru (V práci nám třeba vzniklo pár takových algoritmů v komponentách, které nejlépe měli být v Service, protože pak se jenom kopírovali dál a dál).
- greeny
- Člen | 405
- Texty exceptions by se neměly používat jako texty flashmessagí, exception je informace pro programátora, kde se co podělalo, flashmessage musí být příjemná pro uživatele („Omlouváme se, ale vytvoření účtu selhalo. Zkuste to prosím znovu“).
- Check by měl být na místě, kde dává smysl. Například vytváření
uživatele:
- check na validní username ([a-z0–9]) – form validace
- check na duplicitní username – repo validace
- V presenteru vždy jen odchytíš exception nebo použiješ if (tady už je to celkem jedno, exceptiony jsou obecně víc psaní, ale lepší kontrola, hlavně ale, aby to bylo konzistentní skrz projekt) a vyhodíš flashmessage uživateli.
- jiri.pudil
- Nette Blogger | 1032
- Check by měl být na místě, kde dává smysl. Například vytváření uživatele
- check na validní username ([a-z0–9]) – form validace
Pokud je [a-z0-9] business požadavek, dává kontrola jeho
splnění imo smysl především v modelu (entitě) a až sekundárně (kvůli
UX) ve formuláři. Formulář nemusí být jediným vstupním bodem do
aplikace; uživatele můžeš chtít vytvářet přes API, v konzolovém
commandu…
Editoval jiri.pudil (21. 12. 2016 15:05)