Mam sobie klasę Config, która parsuje plik i udostępnia interfejs do pobierania informacji o ustawianiach konfiguracyjnych. W klasie dozwolona jest zmiana ścieżki do pliku, który ma być parsowany.

Teraz do sedna, jaki typ wyjątku mam rzucić gdy plik nie istnieje lub nie mam uprawnień do odczytu?
LogicException czy RuntimeException ?

Dalej, jeżeli mam tablicę asocjacyjną, podaję klucz do funkcji i ma mi zwrócić wartość, sprawdzam czy klucz istnieje, jeżeli nie istnieje to jaki typ wyjątku rzucić?
InvalidArgumentException ?

RuntimeException gdy nie ma dostępu do pliku - to błąd który jesteś w stanie wykryć tylko podczas działania aplikacji
Jeżeli nie ma klucza ja posługuję się OutOfBoundsException

Co do braku klucza zastanawiałem się właśnie nad tymi dwoma, ten co ja podałem i ten co Ty.
Jednak zależy jak na to spojrzeć? Z jednej strony wynik złego argumentu, z drugiej może chodzić o typ (?), chyba bezpieczniej OutOfBounds.

InvalidArgumentException wywodzi się z LogicException, a w tym przypadku nie powinieneś z niego korzystać. Tak więc OutOfBoundException jest tutaj właściwszym rozwiązaniem.

Swoją drogą wyjątki SPL-a to jedna z tych kompletnie nieprzemyślanych i niedopracowanych części PHP.

A jednak sam mi kiedyś doradziłeś, aby ich używać:
http://forum.php.pl/index.php?s=&showt...st&p=892835

Są niedopracowane ale i tak lepiej z nich korzystać niż tworzyć własną hierarchię kompletnie od podstaw.

U siebie zrobiłem dwie klasy, właściwie to trzy, wzorując się zresztą na symfony. Jedna to jest HttpException, która jest dziedziczona przez NotFoundHttpException oraz AccessDeniedException. W ExceptionHandler sprawdzam czy rzucany wyjątek jest instancją HttpException i jeżeli jest, to z tej klasy jest pobierany "kod" błędu, który w istocie jest kodem błędu http (404 dla NotFoundHttpException oraz 403 dla AccessDeniedException). Chodź równie dobrze wystarczyło by tylko samo HttpException rzucać i przekazać mu odpowiedni kod błędu jako parametr..

No ale w sumie są to jedyne klasy wyjątków, których są niestandardowe, prócz tych trzech, nic ponadto nie tworze

Co na piernik do wiatraka? Pytałem o SPL, co raczej oznacza że mam zamiar z nich korzystać. Poza tym nijak Twoje wyjątki nie odzwierciedlają tego co zamierzam osiągnąć.

myślałem, żeby takie błędy jak brak dostępu do pliku zapisywać w logach, wiadomo że brak klucza w tablicy nie jest raczej czymś co blokuje dalsze wykonywanie skryptu, więc zapisywałbym tylko te krytyczne bez których skrypt nie może dalej pracować

Sorry, chyba mi się tematy pomyliły, albo źle przeczytałem i wyszły z tego banialuki


EDIT:



zależy co ten klucz przechowywał. Jeżeli przechowywał ustawienia do połączenia z bazą danych, to nie blokowanie dalszego wykonywania skryptu, posypało by dalsze części aplikacji które korzystają z bazy danych. Wychodzę z założenia, że jak błąd, to działać nie ma prawa. A w konfiguracji to już szczególne ma to znaczenie

Dobrym pomysłem jest łapanie wyjątków które powodują przerwanie aplikacji i wysyłać wtedy maila / zapisywać w logach - innymi słowy raportować o tym że aplikacja z jakichś względów przestałą działać, osobiście nie wiem co jest lepszym pomysłem : czy wrzucać takie rzeczy np do konstruktora wyjątku (załóżmy że jakiś `programista` zrobił na blok kodu łapanie wszystkich wyjątków i nic z nimi nie robi), czy łapać je i wtedy dopiero podejmować odpowiednie akcje.

Ikar - w przypadku bazy brak jest niedozwolony trzeba rzucić wyjątek, jeżeli dane do połączenia będą złe to wyjątek wyrzuci PDO

Dokładnie za brak klucza w tablicy możesz dostać NOTICE -a, zatrzymanie działania aplikacji będzie przy próbie połączenia i tam wystąpi wyjątek. Bo równie dobrze możesz mieć klucz z błędną wartością.

Akurat co do bazy to wyrzucałbym na poziomie sprawdzania klucza, bo jak mi braknie hostu to po co ciągnąc dalej aplikację.