Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: trigger_error vs. wyjatki
Forum PHP.pl > Forum > PHP > Object-oriented programming
NuLL
Hi all smile.gif

Ostatnio trochę więcej czasu zacząłem poświęcać PHPv5(ale ja opóżnoiony). Wiadomo wprowadzono obslugę wyjątków. Ja od dawien dawna stosuję trigger_error któremu jako ciąg podaję zserializowaną tablicę i po wszystkim - mam fallbacki, nr linii funckje plik i co mi się rzewnie zamarzy smile.gif i wyjatki wydja mi zbedne. Jakie wg. Was plusy posiadaja wyjatki nad trigger'em questionmark.gif Po szczerze mówiąc nie chce mi się definiować miliarda wyjątków dla jakieś większej aplikacji...wole wciąż podpinać własny error_handler...
bela
Wyjątki, jak sama nazwa wskazuje, służą do obsługi sytuacji wyjątkowych.
Czyli np, mamy sobie akcje i w pewnym momencie wystąpi jakaś nietypowa, że tak nazwijmy sytuacja, wtedy wyrzucamy wyjątek ( throw new CannotPerformException() ), a łapiemy go w ten sposób
  1. <?php
  2. try {
  3. $action->perform();
  4. } catch (CannotPerformException $cpe) {
  5. $controller->performOtherAction();
  6. } catch (Exception $e) {
  7. }
  8. ?>

Czyli,
Próbujemy wykonać akcje, jeśli nie powiedzie się to wywołujemy inną akcje (catch(Cann....)), a drugi catch służy do przechwycenia wyjątków które mogły się gdzieś zawieruszyć.

Btw gdzie się finally podziało :]
NuLL
Czyli w pewnym sensie nie musze się aż tak pilnować raportowania błędów ?

Z drugiej sstrony w tym performie() ja moge zadbac o obsluge wszystkich bledów....
bela
Ja jak używałem kiedyś tego trigger_error, to traktowałem to bardziej jako narzędzie debugujące.

Wyjątki eliminują(!) wszystkie w tym momencie zbędne if/else do obsługi błędów, zmiejszają kod i pozwalają na większe ponowanie nad nim.
dasko
Według mnie zaletą wyjątków jest to, że od razu widać, które części kodu są do obsługi błędu, a które nie.

Poza tym definiowanie własnej klasy, dziedziczącej po klasie Exception pozwala na stworzenie specyficznego wyjatku np. dla każdego modułu. A tak to tylko 13 typów błędów wbudowanych.

Ciekawe dlaczego twórcy PHP5 nie zrobili instrukcji finally. Z takim czymś 'wyjątkowość smile.gif' miałaby jeszcze więcej zalet.
Leezard
ja swojego czasu nie moglem sie przekonac do wyjatkow zarowno w C++ jak i w JAVA, uzywalem mnostwa tych nieszczesnych if'ow.
Jednak przy budowie czegos wiekszego, a nawte nie tylko - np patrzac w czyjs kod, na oko widac co jest co, co gdzie lapiesz jesli masz ladnie wyjatki nazwane, poza tym propagacja rzuconych wyjatkow w gore, bez koniecznosci bawienia sie w zwracanie jakis dziwnych rzeczy

a w php finally faktycznie by sie przydalo
bela
Cytat(Leezard @ 2005-03-30 12:41:09)
a w php finally faktycznie by sie przydalo

I jeśli będzie chęć ze strony użytkowników to najprawdopodoniej twórcy php wprowadzą finally, zgodnie z tym co mówili w wywiadzie ( któreś tam php solution, w empiku czytałem więc nie powiem dry.gif ).
hawk
Zresztą wyjątki i trigger_error mają ze sobą mało wspólnego. Wyjątki służą do obsługi błędów, a trigger_error do logowania, debugowania i eleganckiego wywalania aplikacji.
Imperior
tak na marginesie: pamiętajcie o exception_handler()
Vengeance
Z tego co gdzieś wyczytałem, to finally było na liście TODO, ale jakiś user posłał maila, iż jest to wielce nieprzydatne i sztab php finally nie dodał.

Źródła nie podam, nie pamiętam. Może to i błędna informacja :]
NuLL
Ja np. załuje, że wyjątki w SPL i standowych funkcjach gereują tylko konstruktory sad.gif, żeby wszystkie funkcje wywałały wyjątki(tak bez throw tongue.gif) to by było cool cool.gif

@Imperior - handler wyjątków już podpięty smile.gif

Natomiast pomysł z finnaly jest fajny smile.gif Może w 5.1 ?
dr_bonzo
Chyba widzialem takie rozwiazanie na forum: error_handler wylapywal errory i wyrzucal exception.
Imperior
Wydaje mi się, że ta funkcja powinna byc gdzieś w komentarzach manuala.
M4chu
  1. <?php
  2.  
  3. class PHPErrorException extends Exception
  4. {
  5.  private $context = null;
  6.  public function __construct
  7.  ($code, $message, $file, $line, $context = null)
  8.  {
  9.  parent::__construct($message, $code);
  10.  $this->file = $file;
  11.  $this->line = $line;
  12.  $this->context = $context;
  13.  }
  14. };
  15.  
  16. function error_handler($code, $message, $file, $line) {
  17.  throw new PHPErrorException($code, $message, $file, $line);
  18. }
  19.  
  20. function exception_handler(Exception $e)
  21. {  
  22.  $errors = array(
  23.  E_USER_ERROR => &#092;"User Error\",
  24.  E_USER_WARNING => &#092;"User Warning\",
  25.  E_USER_NOTICE => &#092;"User Notice\",
  26.  );
  27.  
  28.  echo $errors[$e->getCode()].': '.$e->getMessage().' in '.$e->getFile().
  29.  ' on line '.$e->getLine().&#092;"n\";
  30.  echo $e->getTraceAsString();
  31. }
  32.  
  33. set_error_handler('error_handler');
  34. set_exception_handler('exception_handler');
  35.  
  36. // Throw exception with an /unkown/ error code.
  37. throw new Exception('foo', 0);
  38.  
  39. ?>
Nievinny
Ciekawe to, muszę przetestować takie rozwiązanie, tylo czy to obsługuje błędy wywalene też przez funkcje takie jak np: set_cookie() ?
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.