Witam,

Niedawno, w momencie gdy Bastion, dał do oceny swojego Debuggera, zaczałem zastanawiac sie jaki to ma sens. Mamy przeciez juz Error Handler, gdy dorzucimy do tego Wyjatki wydaje mi sie, ze to wszystko czego potrzeba.

W moim odczuciu, Error Handler, czyli standardowa obsługa bledów, moze byc jeszcze uzbrojona w dodawanie odpowiedniego wpisu do bazy i wysylanie maila do administratora. Mamy funkcje, set_error_handler, dzieki ktorej mozemy zrobic własny, "ładny", dzieki ktoremu mozemy wlasnie dodac wspomniane przeze mnie wyzej rzeczy i zmienic sposob wyswietlania bledu (tak jakby szablon) i wydaje mi sie ze to wszystko.
Ponadto mamy funkcje error_log, ktora zapisze do logow apacha te bledy.
Jest jeszcze trigger_error(), ktora w momencie istnienia wyjatkow troszke traci sens?

Wyjatki... w moim rozumieniu, przydatne przy takich sytuacjach:

[PHP] pobierz, plaintext 
<?php
try
{
	$q = mysql_query();
	if ( !$q ) { throw new Exception('nie udalo sie zapytanie'); }
}
catch(Exception $e )
{
	echo $e->__toString();
}
?>
[PHP] pobierz, plaintext 

Obsługuja reszte bledów, ktore wynikna w momencie złego działania skryptu. Takze, mozemy dodac do tego "ładniejsze" wyswietlanie informacji o wyjatku, zapisywanie wyjatkow do bazy i powiadomienie mailem do admina. Mamy takze set_exception_handler, ktorej funkcji istnienia do konca nie rozumiem.

W manualu widziałem ciekawe połaczenie Error Handlera i wyjatkow (ktore sa przeciez zwyklym rozszerzeniem EH).

[PHP] pobierz, plaintext 
<?php
 
function handler($errno, $errstr, $errfile, $errline)
{
   print "Error handled!\n";
   throw new Exception($errstr, $errno);
}
 
set_error_handler('handler');
 
try
{
   print 2 / 0; // simple error - division by zero
   print "This will never be printed";
}
catch (Exception $e)
{
   print "Exception catched:\n";
   print "Code: ".$e->getCode()."\n";
   print "Message: ".$e->getMessage()."\n";
   print "Line: ".$e->getLine();
}
 
?>
[PHP] pobierz, plaintext 

Wyjatki obsłuza zarowno typowe wyjatki jak i Error Handlera. Jesli jest to Wyjatek mozemy go zapisac do bazy i wyslac maila, jesli jest to Error, mozemy dodatkowo zapisac go do logow.

Nie widze w takim wypadku sensu istnienia Debuggera, chyba ze ma on jeszcze jakies inne zadania. Jesli sie myle prosze o wyjasnienie...

Po do wywyływać __toString()?
Przecież po to istnieje przeciążenie __toString(), żeby drukować klasy jak inne zmienne. Taki sam znakomity rezultat da:

[PHP] pobierz, plaintext 
<?php
 
 
$oException = new MyException;
echo $oException;
 
 
?>
[PHP] pobierz, plaintext 

Oczywiście zakładamy, że klasa MyException ma przeciążoną metodę __toSrting().

Ale to tak na marginesie
Pozdrawiam.

Tak naprawdę nie jest to debugger, tylko error handler, chociaż ja wolę słowo logger.

Generalnie zastosowania są dwa:
1. Podczas tworzenia aplikacji dobrze jest podpiąć coś, co wyświetli nam wyczerpujące informacje w przypadku wystąpienia błędu. A zatem narzędzie dla developera.

2. W działającej aplikacji powinno się wyświetlać krótki komunikat w przypadku błędu (a więc set_error_handler i set_exception_handler), a szczegółówe informacje gdzieś zrzucić, na ogół do pliku. Znowu potrzebny jest logger.

@hawk: co natomiast sadzisz o samym rozwiazaniu polaczenia Error Handlera / Loggera z Wyjatkami:

[PHP] pobierz, plaintext 
<?php
 
function handler($errno, $errstr, $errfile, $errline)
{
   print "Error handled!\n";
   throw new Exception($errstr, $errno);
}
 
set_error_handler('handler');
 
try
{
   print 2 / 0; // simple error - division by zero
   print "This will never be printed";
}
catch (Exception $e)
{
   print "Exception catched:\n";
   print "Code: ".$e->getCode()."\n";
   print "Message: ".$e->getMessage()."\n";
   print "Line: ".$e->getLine();
}
 
?>
[PHP] pobierz, plaintext 

W ogole zauwazyłem, ze wielu programistow tworzy u siebie kilka klas obslugujacych wyjatki. Przyklad wyciagniety z kodu hwao, z hwao's repository:

[PHP] pobierz, plaintext 
<?php
class SocketUnknownProtocolException extends Exception {}
	class SocketCantConnectException extends Exception {} 
?>
[PHP] pobierz, plaintext 

Po co tworzyc kilka klas obsługujacych wyjatki?

Aby móc na różny sposób lub w różnych miejscach obsługiwać różne typy wyjątków.

Zdefiniuj mi "rozne typy wyjatków"
W tym konkretnym przypadku (ktory podałem) jedna klasa jest identyczna jak druga, rozni sie jedynie nazwa... a czy tu chodzi o nazwy? Wg. mnie moglaby byc to jedna klasa, ktora obsłuzyłaby nie tylko wyjatki ale takze i bledy.

Jak piszecie po angielsku, to chociaz starajcie sie poprawnie :]

Ale wyjątków normalnie nie obsługuje się w sposób, który podałeś. Łapiesz na top-level Exception i wywalasz na ekran. A przecież normalnie robi się catch po fragmencie kodu, łapie określony wyjątek i obsługuje. Jak chchcesz to zrobić dysponując tylko jedną klasą wyjątku? Nie będziesz wiedział, co się stało i nie będziesz w stanie nic zrobić poza wywaleniem komunikatu na ekran i przerwaniem skryptu.

Generalnie jestem przeciwny podanemu przez ciebie kodowi. Czemu ma on służyć? Wyjątki nie służą do wywalania komunikatów na ekran. Nie służą też do logowania błędów. Ani do debugowania aplikacji. Służą do obsługi błędów, a łapiąc zwykły Exception cieżko cokolwiek obsłużyć, chyba że będziemy wstawiać try/catch co drugą linię kodu.

Troszeczke mnie zbiłes z tropu.

Nie wiedziałem, ze wyjatki łapie sie "po trochu" i nie wkłada sie całego kodu w blok try{

Ale czym wiec jest ta obsługa wyjatkow?

"Tradycyjnie"

[PHP] pobierz, plaintext 
<?php
function addData( $file, &$errorStr )
{
	if( $conn = mysql_connect( ... ) )
	{
		if ( mysql_select_db(...) )
		{
			if ( $data =  file_get_contents( $file ) )
			{
				if ( mysql_query( "INSERT INTO table (some_data) VALUES( '" . $data . "' )" ) )
				{
					// OK 
					return TRUE;
				}
				else
				{
					$errorStr = 'zapytanie sie nie powiodlo';
					return FALSE;
				}
			}
			else
			{
			   $errorStr = 'nie mozna bylo wczytac danych';
				return FALSE;
			}
		}
		else
		{
		   $errorStr = 'nie mozna bylo wybrac bazy';
			return FALSE;
		}
 
	}
	else
	{
	   $errorStr = 'nie mozna polaczyc z baza';
		return FALSE;
	}
}
 
 
$errorStr = '';
if ( addData( 'jakisPlik.dat', $errStr ) )
{
	echo "dodalo sie";
}
else
{
	echo "nie dodalo sie, bo" . $errStr;
}
?>
[PHP] pobierz, plaintext 

Z wyjatkami (gdyby funkcje same wyrzucaly wyjatki (jak w PDO), ehh)

[PHP] pobierz, plaintext 
<?php
function addData( $file )
{
	if( $conn = mysql_connect( ... ) === FALSE )
	{
		throw new DB_Exception( mysql_error());
	}
 
	if ( mysql_select_db(...) === FALSE)
	{
		throw new DB_Exception( mysql_error());
	}
 
	if ( $data =  file_get_contents( $file ) === FALSE  )
	{
		throw new File_EXception( ...);
	}
 
	if ( mysql_query( "INSERT INTO table (some_data) VALUES( '" . $data . "' )" ) === FALSE )
	{
		throw new DB_Exception( mysql_error());
	}
}
 
try
{
	addData( 'jakisPlik.dat' );
	echo "dodalo sie"
}
catch ( FileExc. $e1 )
{
	echo "Nie dodalo sie bo: " . $e->getMessage();
}
catch ( DB_Exc. $e2 )
{
	echo "Nie dodalo sie bo: " . $e->getMessage();
}
?>
[PHP] pobierz, plaintext 

Cos w tym stylu, kod oczywiscie nie dziala
Co wyglada na prostsze? Co jest prostsze, czytelniejsze?

a co do set_exception_handler() to warto skorzystac z tej funkcji, aby zaprogramowac obsluge wyjatkow, o ktorych zapomnimy - nie jest znowu o to tak trudno - tak na wszelki wypadek.

@Vomit - nie utozsamiaj wyjatku z bledem. Ty rozumujesz tak. Jesli aplikacja rzuci wyjatek to znaczy ze cos poszlo nie tak. Twoja reakcja na wyjatke ogranicza sie jedynie do zatrzymania aplikacji i wyswietlenie tresi wyjatku na ekranie. Tymczasem przechwycenie wyjatku w stosownym momencie umozliwia podjecie innej alternatywnej akcji, ktora zrealizuje to samo zadanie ale w inny sposob, pominie dana akcje lub w ostatecznosci poinformuje o nie moznosci wykonania danego zadania.

Przyklad

Chcesz pobrac prognoze pogody ktora pobierasz z danego serwisu. Dostajesz wyjatek ze nie mozna polaczyc sie z okreslonym serwisem. Obslugujesz ten wyjatek w ten sposob ze probujesz pobrac prognoze pogody z alternatywnego serwisu. Po pobraniu danych prezentujesz je. Gdybys przechwytywal wyjatek na koncu, juz po probie wyswietlenia danych nie moglbys podjac czynnosci alternatywnych.

Moglbys tez przechwycony wyjatek przekazac dalej i na samym koncu oprocz prezentacji pogody pobranej z alternatywnego serwisu wyswietlibys tez komunikat o niepowodzeniu pobrania informacji z pierwotnego serwisu.

a moim zdaniem lepiej wszystkie wyjątki wyłapywac "na samej górze". Np w moim frameworku wyglada to tak:

[PHP] pobierz, plaintext 
<?php
try{
		$oFC = new FrontController( simplexml_load_file( 'exampleconfig.xml' ) );
} catch( Exception $oException ) {
		echo $oException;
}
?>
[PHP] pobierz, plaintext 

oczywiscie catchy moze byc wiecej ale ogolnie chodzi o to aby wyłapywc wyjątki w jednym miejscu poniewaz jest to czytelniejsze, chyba ze napisalismy plugin do programu i ma on niestandardową obsługę wyjątków. no i nie trzeba sie bawic w set_exception_handler ktore ani ladnie nie wyglada ani nie jest "standardowe" bo np w javie czegos takiego nie ma. Nauczcie sie pisac czysty kod:)

A zeby nie zapomniec o jakis wyjatkach jako ostatni catch dajemy Exception ktory wylapie kazdy wyjatek.

bigZbig: wyjasniłes mi sporo dzieki temu przykladowi.

Nadal jednak nie rozumiem jaka bedzie roznica jak wszystkie wyjatki bede wylapywal za pomoca jednej klasy nazwanej MyException. hawk napisał, ze wtedy nie bede wiedział co sie dokładnie stało, a wg. mnie bede wiedzial, bo po to jest komunikat.

Wyjatku nie lapiesz obiektem *Exception.
Wyjatek jest obiektem, instancja jakiejs klasy pochodnej-od/lub Exception.
Jak bedziesz sprawdzal czy wystapil wyjatek na poziomie bazy danych czy np. z pododu bledu odczytu pliku:

[PHP] pobierz, plaintext 
<?php
catch ( MyException $e )
{
	switch( $e->getMessage )
	{
		case 'Wystapil blad przy zapytanie: SELECT * FROM....':
		case 'Wystapil blad .....':
		case 'Wystapil blad .....':
		case 'Wystapil blad .....':
		case 'Wystapil blad .....':
		case 'Wystapil blad .....':
		case 'Wystapil blad przy laczeniu sie z baza danych':
		// a co jak sie walnales i wpisales message: 'Wystapil bald przy laczeniu sie z baza danych': ?
			{
				// tutaj obsluga bazy danych
			}
		case 'Plik nie istnieje: 'aaa-inc.php':
		case 'Plik jest uszkodzony:
		case 'Plik jest zalockowany':
		case 'Plik .......':
		case 'Brak uprawnien do zapisu do pliku':
		// a co gdy w new MyException( msg ) podales  msg jako 'Brak uprawnień do zapisu do pliku'; ?
	}
}
?>
[PHP] pobierz, plaintext 

a teraz normalnie

[PHP] pobierz, plaintext 
<?php
 
catch ( SQLException $e )
{
   // obsluga wyjatkow z bazy danych, np. wyrzucamy kolejny wyjatek i lapiemy go gdzi
es indziej:
   throw new ApplicationException( 'Blad w aplikacji -- nie mozna kontynuowac' );
   
}
catch ( FileException $e )
{
   // obsluga wyjatkow z plikow
}
catch ( Exception $e )
{
   // obsluga pozostalych wyjatkow
}
 
?>
[PHP] pobierz, plaintext 

Chodzi o to zeby KOD php wiedzial co sie stalo (na podst. klasy wyjatku) a nie zeby user wiedzial (na podstawie tresci komunikatu wyjatku)

@Vomit - jesli wszystkie decyzje po wystapieniu wyjatku beda zalezaly od Ciebie to faktycznie mozesz stosowac tylko jeden ich rodzaj. Jak juz wczesniej napisalem wyjatki mozna zastosowac do sterowania praca aplikacji (przyklad z prognoza pogody) ale aplikacja przecierz nie przeczyta tresci komunikatu. Jedyne czym sie moze pokierowac to rodzajem przechwyconego wyjatku. Ty nadal sprowadzasz wyjatek do komunikatu bledu, a przeciez rzuceniu wyjatku nie musi towarzyszyc wyswietlenie komunikatu.

Poza tym wartość zmiennej Exception::$message może ulec zmianie, a wówczas należałoby to zmienić w każdym miejscu. No i - jeszcze pozostaje kwestia i18n... tak, stosowanie kilku klas dziedziczących po Exception jest IMHO dobrym rozwiązaniem.