Witam, jak lepiej obsługiwać błędy z poziomu klasy?

trigger_error()" title="Zobacz w manualu PHP" target="_manual
Czy wyjątki?

[PHP] pobierz, plaintext 
<?php
throw new Exception('Nazwa klasy :: funkcja() : Jakis blad', 1);
?>
[PHP] pobierz, plaintext 

Do tej pory kożystałem z wyjątków, ale coś mnie podkusiło aby się zapytać co do tego trigger_error()" title="Zobacz w manualu PHP" target="_manual

@edit
Zastanawiam się nad tym dlaczego iż wyjątki nie są aż takie wygodne...
Gdy ktoś ma error_reporting wyłączony to obsługuje klasę jak zwykłe funkcje z jądra PHP, a przy obsłudze wyjątków trzeba try {} i catch{} za każdym razem stosować przy tworzeniu obiektów.

Dziękuję, Babcia@Stefa

Ja bym obstał przy wyjątkach. Ale trochę inaczej. Często można spotkać ten sposób w wielu frameworkach.

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

Wtedy, jeśli masz zamiar inaczej wyświetlać wiadomość

[PHP] pobierz, plaintext 
<?php
class My_Exception extends Exception {
public function getMessage()
{
$sMessage = parent::getMessage();
return 'Błąd: '.$sMessage;
}
}
?>
[PHP] pobierz, plaintext 

i w kodzie

[PHP] pobierz, plaintext 
<?php
thrown My_Exception('jakis tam blad');
?>
[PHP] pobierz, plaintext 

EDIT:
Nie lubie edycji postów. Co do try {} i catch{}. Ja w sowim kodzie wystarczy, że użyje ich raz. Przy uruchomieniu kontrolera, który uruchamia sobie resztę, ale wyjątek i tak zostanie złapany. Bo się w nim mieści.

PS. Przy __autoload() wyjątki siadają niestety

[PHP] pobierz, plaintext 
<?
function __autoload($class) {
	require_once './class/' . $class . '.class.php';
}
 
	define('FOLDER', './templates/');
 
try {
 
	$ini_array = parse_ini_file("config.ini", true);
 
	$db = new db;
	$db->setParam('user', $ini_array['mysql']['user']);
	$db->setParam('pass', $ini_array['mysql']['pass']);
	$db->setParam('name', $ini_array['mysql']['name']);
	$db->setParam('host', $ini_array['mysql']['host']);
	$db->connect();
 
	$action = new action;
	$action->setParam('defClass', $ini_array['action']['defClass']);
	$action->setParam('startClass', $ini_array['action']['startClass']);
	$action->setParam('explode', $ini_array['action']['explode']);
	$action->setParam('exceptions', $ini_array['action']['exceptions']);
	$action->action();
 
} catch (Exception $e) {
	echo 'Wystąpił błąd systemu : <b>',  $e->getMessage(), "</b>\n";
}
?>
[PHP] pobierz, plaintext 

I po kłopocie

autoload" title="Zobacz w manualu PHP" target="_manual

;-/

Niestety

[PHP] pobierz, plaintext 
<?php
public function Error($MESSAGE, $ID='')
	{
		if($this->ErrorReporting == 'Trigger')
			trigger_error($MESSAGE, E_USER_NOTICE);
		else
			throw new Exception('ClassName :: ' .$MESSAGE, $ID);
	}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
$this->Error('Opis', 1);
?>
[PHP] pobierz, plaintext 

Doszedłem do takiego rozwiązania.

Widzę, że chcesz to zrobić elastycznie, ale w przypadku błędów tak się nie da. Zobaczysz to później. Uchwyć się jednego rozwiązania (polecam wyjątki) i nim obsługuj błędy. Przecież i tak od ciebie zalezy jak błędy wyświetlisz, zapiszesz i co z nimi zrobisz. Można nawet robić na własnej klasie obsługi błędów, tylko po co, jeśli mamy udostępnione porządne narzędzie?

Ja wyjątki wyrzucam tradycyjnie, a później

[PHP] pobierz, plaintext 
<?php
catch(Syd_Exception $oException) {
$oController->getPlugin('Error')->display($oException);
}
?>
[PHP] pobierz, plaintext 

I display() zapisuje mi loga z linia, nazwa pliku oraz z post i get itd. oraz wyrzuca stosowny błąd na ekranie. Bardzo fajny jest tracker, dzięki któremu widzę przebieg ładowania programu.

EDIT: To błędów nie wrzucaj nigdy ozdobników tylko suche błędy. I jak najwiecej informacji, co pozwala znaleźć błąd.

@ Babcia@Stefa
Wyjątki są o wiele wygodniejsze, mimo że musisz umieszczać kod w bloku try{} to umożliwia Ci jednak rozpoznanie co to za błąd i naprawę.
Ale nie można tego robić, że masz jedną klasę wyjątków Exception, tylko każdy typ błędu powinien mieć swoją własną, czasem to będzie tylko zmiana nazwy aby móc zastosować pewną konstrukcję:

[PHP] pobierz, plaintext 
<?php
try{
	//jakiś kod
}catch ( JakisMalyBlad $e ){
	//Obsługa tego błędu
}catch ( JakisPowaznyBlad $e ){
	//Obsługa tego błędu, np. wyświetlenie komunikatu użytkownikowi, że coś jest nie t
ak, 
	//a dodatkowo zapisujemy sobie to do logów czy cokolwiek innego.
}//Nie musimy na tym poziomie wyłapywać wszystkich wyjątków, 
//część możemy przepuścić dalej, i te co powodują że nie może działać strona, są o
bsługiwane przez kontroler.
?>
[PHP] pobierz, plaintext 

No i to co napisałe bim2, możemy rozszerzać własne wyjątki, które dadzą nam takie metody które są nam potrzebne.

@Sedziwoj: nie trzeba tworzyć każdorazowo klasy do typu błędu (dobrze jest to robić, ale nie jest to niezbędne). W deklaracji klasy exception widzimy:

[PHP] pobierz, plaintext 
<?php
class Exception {
(..)
protected int $code ;
(..)
final public int getCode ( void )
}
?>
[PHP] pobierz, plaintext 

I prototyp konstruktora wygląda następująco:

[PHP] pobierz, plaintext 
<?php
public Exception::__construct ([ string $message [, int $code ]] )
?>
[PHP] pobierz, plaintext 

Czyli zamiast tworzyć X klas, możemy po prostu wrzucać do parametru $code dowolną stałą / liczbę która może nam zidentyfikować błąd.

A przewaga wyjątków nad trigger_error() jest znaczna - za ich pomocą możesz opanować sytuację i nawet nie wypluwać info o błędzie tylko zaradzić jemu.

Wiesz, nierozróżnienie wyjątku jest przydatne, jeśli jego obsługa jest ta sama, czy prawie ta sama.
Ale jak jest błąd połączenia z baza danych i nieprawidłowe parametry, to jednak powinny to być inne wyjątki, bo co innego się robi. Jak już masz błąd połączenia, to możesz kodem opisać co jest przyczyną.
Taki ja mam pogląd.

@Sedziwoj: no ja się zgadzam z tobą, sam nawet stosuję te rozróżnienie na klasy, chciałem tylko przedstawić sprawę w innym świetle.

oczywiscie polecam rozwiazanie polegajace na wyjatkach. niewatpliwie jest ona bardziej elastyczne (ze wzgledu na mozliwosc chociazby zagniezdzenia blokow try{} catch{} wiec mozesz umiescic swoj starszy kod wewnatrz takiego bloku i nie bedzie problemu) a jednoczescie umozwiliajace dosc dobra kontrole nad przebiegiem wydarzen (jak widac na poszczegolnych juz przytoczonych przykladach mozna dosc szczegolowo kontrolowac zdarzenia zaleznie od tego, jaki blad wystapi). najwazniejsza przewaga wyjatkow nad trigger_error() jest to, ze jest to kontrukcja jezykowa (jak takze widac).

ze swojej strony moge dodac klase wyjatkow, ktora w nieznaczny sposob modyfikuje zachowanie klasy bazowej, a umozliwia proste rozroznienie wyjatkow tej samej rodziny po konkretnych przypadkach (kodach bledow):

[PHP] pobierz, plaintext 
<?php
 
/**#@+
 * @version 0.1.2
 * @since 0.0.6
 */
 
/**
 * @package POT
 * @author Wrzasq <wrzasq@gmail.com>
 * @copyright 2007 (C) by Wrzasq
 * @license <a href=\"http://www.gnu.org/licenses/lgpl-3.0.txt\" target=\"_blank\">http://www.gnu.org/licenses/lgpl-3.0.txt</a> GNU Lesser General Public License, Version 3
 */
 
/**
 * Generic exception class for error codes.
 * 
 * @package POT
 */
class E_OTS_ErrorCode extends Exception
{
/**
 * Sets error code.
 * 
 * @param int $code Error code.
 * @param string $message Optional error message.
 */
	public function __construct($code, $message = '')
	{
		parent::__construct($message, $code);
	}
}
 
/**#@-*/
 
?>
[PHP] pobierz, plaintext 

http://opentibia.svn.sourceforge.net/viewv...S_ErrorCode.php

oczywiscie roznica jest nieznaczna, ale z poziomu kodu o wiele wygodniej jest obslugiwac kody bledow, niz ich wiadomosci.

Jeśli masz gdzieś rozpiskę tych kodów, co jaki znaczy. Mi prościej jest przekazać cały błąd i informację z nim związane, np "Can't load file [ścieżka do pliku]". Oczywiście gdy user nie ma praw wyświetla mu się identyfikator błędu oraz ja dostaje powiadomienie na emaila. Szybciej się debuguje aplikację niż szukać jaki kod co oznaczał.

Bledy phpowe sa do D....., nic ci nie daja, wywala napis na ekran [ktorego w 99% nie chcesz tam widziec] a program leci sobie dalej, co z tego ze nie polaczyles sie z baza, skrypcik proboje na tym nieistniejacym polaczeniu wywolywac zapytania [a wyjatek ucieknie ci poziom wyzej, a dokladniej do pierwszego catch'a i nie pozwoli ci na takie bezsensowne akcje w skrypcie].
Mozesz przeciez uzyc IF'y, wszedzie, prawie co linijke, az szlak cie trafi. No i tracisz jedna z wartosci zwracanych przez funkcje, ktora musisz przeznaczyc na pokazanie ze nastapil blad.

Ja nie korzystam z kodow bledow w wyjatkach [moze sie kiedys przydadza, ale na razie nie byly mi potrzebne], kazdy rodzaj bledu ma swoja klase np. RecordNotFound, FileNotFound, RoutingError, i jako msg przekazuje jakies dane odpowiednio NazwaKlasy + id, nazwa pliku, parametry requestu. Rozpoznawanie po kodzie bledu jest lipne, bo musisz dopisac funkcjonalnosc ktora juz masz [obsluge wielu catch'y], zamiast po prostu utworzyc kilka klas wyjatkow [1000x czytelniejsze]