[yarel napisał(a)]
Chodziło mi o to, żeby dostarczyć developerowi informację o łańcuszku problemów, które się pojawiły. Możesz mieć jeden wyjątek z różnymi komunikatami albo rozmnożyć te wyjątki.
Tylko że mój przypadek to nie jest łańcuszek problemów, prędzej szereg :) Nie są swoimi przyczynami.
Skoro masz dwa wyjątki do wyboru: A i B, to masz możliwości:
- A jest przyczyną B
- B jest przyczyną A
- A nie jest powiązane z B
Zapomniałeś o "A i B wynikają ze wspólnej przyczyny C" ;)
Wówczas masz do wyboru nie 2 wyjątki, a 3, więc tak średnio zapomniałem, ale nie nie wiem czy jest sens drążyć ilość tych wyjątków i rozważać grafy wyjątków. KIS ;-)
Niezależnie, który wyjątek rzucisz, to skąd developer ma wiedzieć jak zareagować na błąd bez wiedzy o relacji między A i B ?
One są od siebie niezależne. Najpierw programista musi się uporać z jednym, potem z drugim. Pytanie z tematu dotyczy, właśnie tego z którym z nich jako pierwszym.
Przecież to będzie Exception Driven Development, które postrzegane jest jako anty wzorzec. Co innego, gdy dostarczasz szczegółowej informacji co poszło nie tak i dlaczego, a co innego gdy wymuszasz na użytkownikach obsługiwanie najpierw czegoś, a później czegoś innego.
Offtopic (w stosunku do pytania: który wyjątek rzucać). Jaki problem developera chcesz rozwiązać? Jak developer nie ma kontroli nad argumentami przekazywanymi do Twojego API, to jak ma niby reagować na wyjątek? Coś innego niż logowanie komunikatu błędu?
Jeśli nie ma (w co wątpię, bo to developer korzysta z API), to faktycznie NIC. Jeśli natomiast ma (co będzie 99.99999% użyć), to obsłuży sobie to jak będzie chciał, i jestem niemal pewien że rzucenie odizolowanych od siebie wyjątku będzie lepszym pomysłem, ponieważ wystąpienie ich na raz będzie raczej rzadkie. Dużo częstsze będzie wystąpienie tylko jednego z nich.
Jeśli chodzi o dostarczenie informacji dlaczego dany kawałek kodu się wywalił w trakcie developmentu, to lista komunikatów o naruszenie reguł API w zupełności by mi wystarczyła (posortowane po przyczynach, tak bym był w stanie zorientować się od czego zacząć sprawdzenie kodu).
Jak już mówiłem, 99.99999% przypadków to będzie lista wielkości 1.
Wydaje mi się, że to estymata z... palca. Skąd wiesz ilu developerów i w jaki sposób będzie korzystać z biblioteki, żeby wyciągać wnioski, że będzie to praktycznie niezauważalny przypadek?
Jeśli jednak tak będzie, to moim zdaniem nie warto dla 0,00001% przypadków komplikować rozwiązania. KISS & fail fast.
Na "produkcji" raczej chciałbym mieć możliwość podmieniania komunikatów błędów z wyjątku na bardziej biznesowe i możliwość tłumaczenia komunikatu na różne języki, czyli jakiś domyślny tekst błędu + klucz po którym mógłbym wybierać biznesowy opis błędu, np. Exception=(msg="Invalid argument",rc="RC01") (RC01 - result code 01, używane jako klucz do tłumaczenia na biznesowe/międzynarodowe na jakiejś innej warstwie - Francuzi często chcą mieć logi po swojemu :-) ).
Biblioteka nie dotyczy w żaden sposób warstwy prezentacji, więc odpowiedź nie na temat.
Czyli zakładasz, że wiesz lepiej od końcowego użytkownika do czego będzie używał biblioteki, a do czego nie?
Moim zdaniem trochę średni pomysł. I potem wyobrażasz sobie testowanie tego w phpunit?
Nie znam phpunita, więc się nie będę wypowiadał.
Ok, wyobrażasz sobie testowanie takiej "listy wyjątków" w jakimkolwiek narzędziu do testowania?
Tak samo jak jakiejkolwiek innej zwracanej "listy". Skoro kontroluję stan wejściowy i oczekuję konkretnego zachowania, to na wejściu spodziewam się konkretnego wyniku ("konkretnej listy"). Jak to będzie wyglądać w z perspektywy użycia jakiegoś frameworka testowego? To zależy od tego co framework udostępnia. Jak pisałem, nie znam phpunita i nie wiem czy jest to w PHP do zrobienia, być może nie, nie wiem.
W Javie można tak (https://junit.org/junit5/docs/5.0.1/api/org/junit/jupiter/api/Assertions.html) :
FooException fooExcption = assertThrows( FooException.class, () -> someObject.doSomeMagic(), "doSomeMagic should throw, but it didn't");
// fooException daje Ci możliwość zbadania fooException.getRootCause() i jakichś dodatkowych asercji
Dostałeś propozycje różnych opcji, ale mam wrażenie, że:
- pytasz o opinie, żeby zrobić api "dev friendly".
No jasne, cytując klasyka, "programy powinny być pisane dla ludzi do czytania, i okazyjnie dla komputerów do uruchomienia".
- odrzucasz propozycje i robisz po swojemu. Twoja biblioteka, więc Twój wybór, tylko czy wówczas jest "dev friendly" ? :)
Propozycje które są nie na temat, albo nie spełniają pewnych kryteriów, siłą rzeczy muszą być odrzucone.
Moim celem nie jest przekonanie Cię do czegokolwiek, tylko pokazanie innych możliwości. To Ty lepiej znasz kontekst względem, którego oceniasz co lepiej pasuje do Twojego pomysłu i tyle. Rzucaj co uważasz za słuszne ;-)