Zastanawiam sie jak rozwiazac problem z wyjatkami, otoz:
Tworze sobie pochodne klasy Exception:
MessageException (mniej powazne bledy)
FatalException (powazny blad zatrzymujacy dzialanie aplikacji)

MessageException chcialbym uzywac np. do problemow typu: Niepoprawne ID, Nie ma takiego rekordu w bazie, etc., a FatalException do sytuacji gdy np. nie ustanowiono poleczenia z db

[PHP] pobierz, plaintext 
<?php
class DB
{
			 // laczy z baza, w razie niepowodzenia zwraca:
			 throw new FatalException( 'Niestety nie ustanowiono polaczenia z baza!' );
}
 
class Users
{
	function __construct( $iID )
	{
		if( !is_numeric( $iID ) )
		{
			 throw new MessageException( 'Niepoprawne ID' );
		}
}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
$oDB = new DB; //laczenie
 
try
{
	// wyswietlanie podstawowego widoku (header)
 
	$oU = new Users( 'a' );
 
	// wyswietlanie podstawowego widoku (footer)
}
catch( Exception $oE )
{
	echo $oE -> printError();
}
?>
[PHP] pobierz, plaintext 

Efektem tego ma byc ze jezeli nie polaczy sie z baza dostanie na ekranie tylko komunikat o bledzie (FatalException), zas jesli wystapi blad w klasie Users (MessageException) to wsywietlony zostanie szablon z komunikatem o bledzie (header, komunikat, footer)

Jak to rozwiazac?

Nie wiem czy dobrze rozumiem?
Skonkretyzowac instrukcje catch dla 2 typow wyjatkow?

[PHP] pobierz, plaintext 
<?php
try{
// instrukcje
}catch(MessageException $e){
// akcje implementujace wyswietlanie komunikatu
}catch(FatalException $e){
// akcje implementujace obsluge szablonu i przesylanie/wyswietlanie komunikatu
}
?>
[PHP] pobierz, plaintext 

FatalException moze zawieszac wykonywanie programu i rzucac na ekran tresc bledu, a MessageException moze rejestrowac gdzies tresc komunikatu (zakladam, ze moze byc kilka bledow przy 1 uruchomieniu programu a header masz juz wyslany) po czym wyswietlic zarejestrowane komunikaty i footer.

... chyba chodzi o to, że po wywołaniu wyjątku typu MessageException() ma się gdzieś zapisać informacja o błędzie, i program ma wrócić do dalszego wywoływania kodu. Natomiast w przypadku wywołania FatalException() ma przerwać działanie aplikacji.

Niestety nie da się (albo nie znam sposobu) zrobić to w taki prosty sposób, Ponieważ wyrzucenie wyjątku to wyrzucenie wyjątku, więc program i tak pójdzie do obsługi... a stamtąd raczej nie ma prostego powrotu. Chyba lepszym wyjściem będzie po prostu użycie jakiegoś innego rodzaju klasy do notowania MessageException(). Coś na styl:

[PHP] pobierz, plaintext 
<?php
class MessageException{
  function __construct($msg){
	$this->writeToLogFile($msg);
	$this->notifyUser($msg);
  }
  //... itd
}
?>
[PHP] pobierz, plaintext 

Po prostu ją wywołujesz a potem skrypt działa dalej.

@Cezar708: Chyba tez tak to widze, innego rozwiazania nie ma, MessageException to imitacja wyjatku:/

Używanie wyjątków do informowania o tym, że coś poszło nie tak jest jak najbardziej na miejscu, jakkolwiek ograniczanie się tylko do 2 typów już nie jest trafne. Skorzystaj z pełni możliwości jakie oferują Ci wyjątki do tego by komunikować różne sytuacje. Generalizacja na dwa stopnie - wyjątek groźny i niegroźny jest złe, ponieważ po drodze jest cała gama problemów z którymi radzisz sobie w różny sposób a typ złapanego wyjątku od razu ułatwia Ci diagnozę (stacktrace + typ). Rozróżnienie fatal/warning/notice to w gruncie rzeczy poziom programowania strukturalnego i trigger_error. Zrób coś więcej..

[PHP] pobierz, plaintext 
<?php
class BaseSystemException extends Exception {}
 
class DatabaseException extends BaseSystemException {}
class ConnectionException extends DatabaseException {}
class QueryException extends DatabaseException {}
 
class IOException extends BaseSystemException {}
 
// z takim kodem możesz zrobić np:
try {
	new DatabaseManager($url);
} catch (ConnectionException $e) {
	// problem z połączeniem
} catch (QueryException $e) {
	// np problem z SET NAMES po połączeniu
} catch (DatabaseException $e) {
	// nieznany błąd związany z bazą danych
} catch (IOException $e) {
	// błąd odczytu np konfiguracji
} catch (BaseSystemException $e) {
	// błąd zgłoszony w Twoim kodzie
} catch (Exception $e) {
	// błąd, którym sypnęło np PDO
}
 
?>
[PHP] pobierz, plaintext 

No nie zabardzo splatch, ja widze to raczej tak (podzial na bledy i bledy krytyczne):

[PHP] pobierz, plaintext 
<?php
try
{
	// szablon header
 
	if( MessageException )
	{
		// szablon bledu maloznaczacego/ostrzezenia
	}
	else
	{
		// szablon wlasciwy wywlanej poprawnie akcji
	}
 
	// szablon footer
}
catch( FatalException )
{
	// tylko szablon bledu krytycznego, brak wyswietlania jakichkolwiek elementow stro
ny
}
?>
[PHP] pobierz, plaintext 

Jak widac pierwsza czesc bloku try wyswietla szablon calej strony z ostrzezeniem (np. nie podano id) lub zawartoscia akcji (wyswietlony user), zas druga czesc bloku zatrzymuje cala aplikacje i wyswietla komunikat o krytycznym bledzie (np. brak polaczenia z db)

kicaj zanim zapniesz wyjątki do walidacji zastanów się kto powinien obsługiwać błędy walidacji bo sprawa obsługi błędów i walidacji to dwie różne rzeczy, no chyba że chcesz traktować błędy z inputu na równi z błędami systemowymi. W końcu możesz mieć FatalException przy połączeniu do bazy danych i FatalException przy walidacji, bo ktoś nie podał wartości w polu user_login. Z resztą walidację omawiamy już w oddzielnym temacie i sugestie z użyciem wyjątków do walidacji powinny trafiać tam, a nie tu, jak sądzę.
Myślenie o wyjątkach w dwóch kategoriach - krytyczne i "nie krytyczne" jest złe bo nie masz rozróżnienia na kontekst wystąpienia błędu i zawężasz sobie pole do ich obsługi. W końcu nie wszystkie FatalException-y obsługujesz tak samo. Obsługa wyjątków w try/catch przez instanceof jest prawdę powiedziawszy lekkim naginaniem zasad związanych z przeznaczeniem wyjątków i zastosowaniem bloku catch. Nie odbiega to od trigger_error zatem zastanów się czy piszesz obiektowo czy też bawisz się w przeplatanie.

Kwestia wyjątków w akcji - obsługujesz tylko te, które rzeczywiście musisz. W większości przypadków możesz wydelegować ich obsługę do FrontControllera i pozbyć się śmieci z logiki.

I może ja się wypowiem kilka słów na temat wyjątków.
Ograniczenie klas wyjątków do właśnie dwóch klas Fatal i Notice ( czy jak je tam nazwiesz ), nie jest zbyt dobrym rozwiązaniem.
Z tego względu że doprowadza do sytuacji w której nie wiesz tak na prawdę na jakim etapie coś padło.
Nie jesteś w stanie dla odpowiedniego błędu przygotować akcji zastępczej, no chyba że zrobisz duuuży switch z numerami błędów, nie wspominając o tym aby pamiętać który numer co robi.
A dolicz sobie do tego zle wyłapywanie wyjątków w zagnieżdzonym try...catch Popatrz:

[PHP] pobierz, plaintext 
<?php
class Klasa
{
	public function add()
	{
		 try {
			  ...
			  $this->db->insert(); // Tutaj takze moze wywalic wyjatek FatalErrorException
			  ...
			 // Jakies operacje ktore wywala wyjatek FatalErrorException
			throw new FatalErrorException("Uhh nie udalo sie");
			 ...
		} catch ( FatalErrorException $e ) {
		   // Który throw złapaliśmy?
		}
	}
}
 
try {
$o->add();
} catch( FatalErrorException $e ) {
 // Czy to nam się wywoła? 
}
?>
[PHP] pobierz, plaintext 

Ja jestem za tym, żeby wyjatki były obdługiwane na odpowednim poziomie. Jeśli mamy błędy powstałe w samej logice aplikacji (coś źle poszło), to wypluty wyjątek powinien byc zwiazany z akcją. np.

[PHP] pobierz, plaintext 
<?php
class cosNieTakException extends actionException{}
?>
[PHP] pobierz, plaintext 

Jeśli walidacja jest we froncie, to powinna mieć odpowiednio

[PHP] pobierz, plaintext 
<?php
class validatorException extends frontException{}
class unexpectedInputDataException extends validatorException{}
?>
[PHP] pobierz, plaintext 

i powinny być obsługiwane przez odpowiedni handler błędów (obiekt) we front controlerze (choc w sumie nie wiem, czy to dalej jest Front Controller. U mnie rozrósł się tak, ze chyba będę potrzebował jakiejś dobrej refektoryzacji.)

[PHP] pobierz, plaintext 
<?php
$err=new frontExceptionHandler(); 
try{}
catch()
{
  $err->handle(validatorException $exception) //pokazuje wymuszanie typu tylko aby zobrazować
}
?>
[PHP] pobierz, plaintext 

Pewnie macie racje z tym nie slusznym rozdzieleniem wyjatkow na krytyczne i mniej krytyczne...

Jednak na tyle ile mi potrzebne spelnia moje oczekiwania, efektem czego jest przy np. braku polaczenia z db, zachowuje sie jak normalny wyjatek, zatrzymuje aplikacje i informuje o bledzie, drugi sposob jak juz wczesniej bylo powiedziane jest to czesciowa imitacja wyjatkow z tym ze aplikacja wykonuje sie, tylko jest informowana o danym bledzie w danej akcji, reszta dziala bezproblemu-dalej. Pewnie z czasem rozbudowy tegoz kodu odczuje wasze uwagi i wtedy przejde na prawdziwy OOPowe wyjatki, tymczasem mam jak to nazwal splatch "przeplatanie"...