Jak duży blok try catch Opcje

[hugo_amv]

Na pewnej mądrej stronie ( nie pamiętam jakiej, może na java.sun.com, ale na pewno źródło było dość pewne) spotkałem się z opinią, że nie powino się umieszczać duży bloków kodu pomiędzy try catch, a jedynie krótkie fragmetny kodu i odrazu przechwytywać błędy. Ja wolę wszystkie wyjątki przechwytywać w silniku strony, a dopiero potem zajmować się ich obsługą.

[PHP] pobierz, plaintext 
<?php
try{
	/**
	 * Tutaj różne moduły, uruchamiaja różne klasy,
	 * które zwracają różne wyjątki :)
	 */
}catch (SQLException $e){
	// Obługa wyjątków związanych z bazą danych
	echo $e;
}catch (FileException $e){
	// Inny typ wyjątków
	echo $e;
}catch (Exception $e){
	// Pozostałe rodzaje błędów
}
?>
[PHP] pobierz, plaintext 

Jednak na tamtej stronie było wyraźnie napisane, że jest to złą praktyką programistyczną. Jak to w końcu jest?

[hugo_amv]

W sumie to się za bardzo rozpędziłem. Może inaczej. php po wyrzuceniu wyjątku przecodzi na koniec try{} i przechodzi przez wszystkie catch aż znajdzie odpowiedni. Przy dużej ilości wyjątków po jednym catch może to na prawdę trochę zająć.

Masz na myśli dużej ilości rodzajów wyjątków (różne klasy wyjątków)? U mnie nie ma dużej liczby 3, 4 podstawowe klasy wyjątków, reszta do domyślnego boku catch

Wiesz co do obsługi nieznanych wyjątków. Po to się tworzy nowe typy wyjątków żeby je odpowiednio obsłużyć. Reszte możesz co najwyżej wyświetlić albo zrobić ew jeszcze switch{}(w domyslnym bloku) i sprawdzać kody błędów. TYLKO PO CO? Czytelność i przenośność to podstawa.

No właśnie! Moim zdaniem obsługa wyjątków jednym miejscu jest bardziej czytelna niż rozdzielanie tego na kilka/ kilkanaście bloków try catch

Masz tu chipotetyczną sytuację.
Tworzysz jakąś klasę np do obsługi księgi gości. Genreuje ona ew kilka charakterystycznych wyjątków. Jeżeli to twój projekt to pozostaje Ci tylko przekopiowanie wszystkich bloków catch które dotyczą tych wyjątków (tutaj łatwo o pomyłkę) i wklejenie ich do nowego projektu.

Nierozumiem co gdzie wklejam (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Gorzej jeżeli to projekt zewnętrzny(jak większy to pewnie jeszcze z wykorzystaniem MVC). Z resztą wyjątki możesz podzielić na 2 grupy:
1. Te które może obsłużyć sam moduł.
2. Te które wymagają akcji konkretnego programisty.
Skąd możesz wiedzieć czy ICH projekt też jest cały w try{}. Może zależnie od widoku admin będzie chciał inaczej obsłużyć konkretny wyjątek? I za każdym razem wklejanie kodu z catch{} wyjątków typu 1 tam gdzie używasz klasy/modułu? Masz wtedy trochę zabawy. :/

Jeżeli pisze jakiś moduł / klase do istniejącego już projektu to najpierw czytam jego dokumentacje, komentarze w kodzie, a potem w zależności jak autor rozwiązał mechanizm obsługi wyjątków dostosowuje swój moduł.

A gdy ktoś będzie chciał napisać moduł do mojego projektu (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) lub wykorzystać moją klase do komunikacji z bazą danych, zapozna się z kodem (komentarzami) i zobaczy, że zwraca ona wyjątek SQLException, który musi obsłużyć.

Może jestem wyjątkowo uparty, ale narazie żadne argumenty to mnie nie trafiają. Nie otrzymałem jednoznaczej odpowiedzi co jest złego w moim podejściu do łapania wyjątków. Jeśli pracuje w zespole to zasady są odgórnie ustalone. Albo jest po mojemu albo po waszemu (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)