Intotdeauna am avut o problema cu aceasta problema. De fiecare data am folosit cate o strategie si niciodata nu am simtit ca am raspunsul.
Aici e o buna prezentare a solutiilolor de a ataca problema.
Cred că depinde foarte mult de scopul metodei. În cazul unei autentificări (fix exemplul cu Jeffrey) cred că null este fix ce trebuie să întoarcă o metodă în cazul în care autentificarea eșuează.
throw cred că este un pic prea mult și ți-ar putea transforma foarte ușor aplicația într-o succesiune de try/catch.
Is it just me sau link-ul nu functioneaza?
In afara de asta, tind sa fiu de acord cu @iamntz. Imi aduc aminte de pe vrmea cand lucram in Java, ca aveam plin de try / catch in code si niciodata nu eram multumit de modul in care ar trebui sa esueze ceva, in sensul ca unul la mana nu eram sigur niciodata daca ceva arunca o exceptie cum trebuie si intre in catch si doi la mana faptul ca, in momentul cand ai o aplicatie enorma care are enorm de multe de linii de cod, poate try / catch nu este cea mai human readable solutie. De aceea cred ca o metoda clara ar trebuie fie sa returneze fie raspunsul sau null.
Chestia cu exceptiile este intr-adevar o politica aparte. Trecerea mea la php de la java m-a dezobisnuit.
Apoi a venit php 5 si a trebuit sa regandesc cu exceptii. Regula e simpla: arunc o exceptie atunci cand ceva atipic logicii mele apare ( in mod exceptional).
Exemplu: daca aplicatia mea suporta si uset neautentificat atunci nu e o exceptie sa nu am user id. Dava totusi logica spunea ca mereu idul sa fie id de user, atunci arunc exceptia.
Nivelul la care tratezi exceptiile (stabilind astfel scopurile) este cheia “citibilului”
3 Likes