Czy jest sposob na obsluge wyjatkow funkcji wbudowanych w php. Chodzi mi o include ('plik'), gdzie po wpisaniu nieistniejacego pliku bede mogl wykonac wlasna funkcje a nie ze parser informuje mnie o tym ze pliku nie znaleziono.

Niestety - nie.
W tej chwili php nie ma jeszcze pełnej obsługi wyjątków, to znaczy, że większość wbudowanych funkcji nie zwraca wyjątków, tylko errory i notice.

W takim przypadku jedynym rozwiazaniem jest napisanie funkcji myInclude i samodzielna obsługa i weryfikacja takich wydażeń.

Poczytaj o funkcji __autoload() i poszukaj na forum. Temat był poruszany nie raz, jest pewna możliwość, ale jest trochę zabawy.
forum.php.pl :: search :: autoload

Może się mylę, ale chyba można coś zwojować używając set_error_handler" title="Zobacz w manualu php" target="_manual()...?

Jasne że można, ale to nie to samo co natywna obsługa

Niestety mimo znacznego usprawnienia modelu obiektowego w php5, w tym obsługi wyjątków, większość standardowych funkcji języka, z których korzystamy na co dzień ciągle zorganizowane są w sposób proceduralny i nie zwracają wyjątków w razie niepowodzenia wykonania. Więc nie jest możliwe zamknięcie ich wywołania w bloku try i przechwytywania wyjątków. W takich przypadkach php zwraca błędy różnych poziomów w zależności od błędu.

Korzystając z funkcji set_error_handler mamy możliwość część tych błędów przechwytywać. Oto w jaki sposób przy wykorzystaniu tej funkcji + set_exception_handler ja radzę sobie z obsługą zwykłych błędów za pomocą wyjątków. Pomysł polega na tym, żeby funkcja set-error-handler wyrzucała napisany na tą potrzebę przez nas wyjątek. Dla pewności ustawiamy obsługę nieprzechwyconych wyjątków w set_exception_handler. W bardzo uproszczonej formie wygląda to następująco (kod w php5):

[PHP] pobierz, plaintext 
<?php
/**
  * Klasa obsługi błędów i nieprzechwyconych wyjątków
  **/
class ErrorHandler
{
   /**
    * Konstruktor 
    *
    * Możemy w tym miejscu ustawić o jakich błędach php ma nas informować
    *
    * @return ErrorHandler
    * @access public
    **/
   public function __construct()
   {
      // trzeba pamiętać że E_ALL ma wartość 2047 podczas gdy 2048
      // a chcemy przecież wiedzieć o wszystkich błędach
      error_reporting( E_ALL | E_STRICT );
   }
 
   /**
    * Obsługa błędów 
    *
    * @param integer Kod błędu
    * @param string Opis błędu
    * @param string Plik w którym wystąpił błąd
    * @param integer Numer linni kodu
    * @return void
    * @access public
    * @throws ErrorException
    **/
   public function handleError( $iErrNo, $sErrStr, $sErrFile, $sErrLine )
   {
      set_exception_handler( array( $this, 'handleException' ) );
 
      // funkcja error handler przechwytuje wszystkie błędy nawet w przypadku
      // wywyołań  funkcji poprzedzonych @ dla których error_reporting = 0
      if ( error_reporting() != 0 )
      {
         throw new ErrorException( $sErrStr, $iErrNo, $sErrFile, $sErrLine );
      } 
   }
   
   /**
    * Obsługa nieprzechwyconych wyjątków 
    *
    * @param Exception
    * @return void
    * @access public
    **/
   public function handleException( $oE )
   {
      echo '<pre>';
      echo $oE->__toString();
      echo '</pre>';  
   }
}
 
?>
[PHP] pobierz, plaintext 

Klasa wyjątku mogłaby wyglądać tak:

[PHP] pobierz, plaintext 
<?php
class ErrorException extends Exception
{
   /**
    * Konstruktor 
    *
    * @param string Opis błędu
    * @param integer Kod błędu
    * @param string Plik w którym wystąpił błąd
    * @param integer Numer linni kodu
    * @return ErrorException
    * @access public
    **/
   public function __construct( $sMessage, $sCode, $sFile, $sLine )
   {
      parent::__construct( $sMessage, $sCode );
      $this->file = $sFile;
      $this->line = $sLine;
   }
   
   /**
    * Reprezentacja obiektu w formie łańcucha tekstu
    *
    * @return string
    * @access public
    **/
   public function __toString()
   {
      $sMsg = $this->message . '<br />' . $this->file . '(' . $this->line . ')<br/ >';
      return $sMsg;
   }
     
}
 
?>
[PHP] pobierz, plaintext 

Należałoby oczywiście dla każdego typu błędu stworzyć specjalistyczną klasę wyjątku i odpowiednio je obsługiwać.

Użycie powyższego kodu sprowadza się już tylko do ustawienia napisanej przez nas funkcji obsługi błędów i przechwycenia odpowiedniego wyjątku:

[PHP] pobierz, plaintext 
<?php
...
   public function testErrorAsException()
   {
      set_error_handler( array( new ErrorHandler(), 'handleError' ) );
      $bExceptionCaught = false;
      try
      {
         constant( UNDEFINED_CONSTANT );
      }
      catch ( ErrorException $oE )
      {
         $bExceptionCaught = true;
      }
      $this->assertNoErrors();
      $this->assertTrue( $bExceptionCaught );
      $this->assertEqual( 38, $oE->getLine() );
      $this->assertWantedPattern( '/UNDEFINED_CONSTANT/', $oE->getMessage() );
   }
...
 
?>
[PHP] pobierz, plaintext 

Podejście jest oczywiście bardzo ubogie i nie wolne od błędów. Trzeba między innymi pamiętać o tym, że nasz error_handler nie będzie przechwytywał błędów typu E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING i części E_STRICT, z którymi nic nie zrobimy.


Nie bardzo rozumiem co ma wspólnego funkcja __autoload() z pytaniem zadanym przez reekz

Z poważaniem,
kf

P.S. Takiego samego posta na podobne pytanie umieściłem na innym polskim forum. Zdecydowałem się zamiast podać linka napisać go tutaj jeszcze raz. Mam nadzieje, że jest to zgodne z tutejszymi zasadami.


poprawiam
---
nospor

[PHP] pobierz, plaintext 
<?php 
 
class IOException extends Exception {}
 
function ExceptionHandler( $sReson = null, $sException = 'Exception' ) {
   throw new $sException( $sReson );
}
 
try {
 
   $aFile = File( 'hwao' ) or ExceptionHandler();
 
}
catch( exception $ex ) {
   echo $ex;
}
 
try {
   $aFile = file( 'cos' ) or ExceptionHandler( 'Plik nie istnieje!', 'IOException' );
}
catch( IOException $e ) {
echo $e;
}
catch( Exception( $e ) {
echo $e;
}
 
// Bardziej hard mozna tak
function exFile( $sFile ) {
   return file( $sFile ) or ExceptionHandler( 'Plik nie istnieje!', 'IOException' );
}
 
try {
  exFile( 'aaa' );
}
catch( exception $e ) {
echo $e;
}
?>
[PHP] pobierz, plaintext 

Jak zwykle inprowizuje i nie sprawdzalem tego.. ale powino dzialac.

[PHP] pobierz, plaintext 
<?php
if (file_exists ('plik')) include ('plik');
else throw new Exeception ('Nima pliku');
?>
[PHP] pobierz, plaintext 

To że na każdy problem istnieje wiele rozwiązań, nie znaczy że są one dobre.

Jednym z podstawowych zadań i ogromną zaletą wyjątków jest oddzielenie kodu odpowiedzialnego za obsługę błędów od kodu aplikacji. Pozbycie się uciążliwego i koszmarnego do opanowania w bardziej skomplikowanych przypadkach tzw. inline error checking, na rzecz bloku try.

Więc propozycje typu:


Nie są najlepszym rozwiązaniem i mijają się z celem. Zamiast pomagać, wprowadzają niepotrzebne zamieszanie utrudniając czytanie kodu.

napisz wlasny odpowiednik funkcji:

[PHP] pobierz, plaintext 
<?php
 
function dolacz ($plik)
{
if (file_exists ($plik)) include ($plik);
else throw new Exeception ('Nima pliku '. $plik);
}
 
?>
[PHP] pobierz, plaintext 

poprawiam
---
nospor

To też nie jest najlepszy pomysł i nie polecałbym go. Zaśmieca kod, który staje się niezrozumiały dla innych programistów, ze względu na przysłanianie standardowych funkcji własnymi nazwami.

Wszystko ok, tyle że klasa ErrorException już istnieje:

[PHP] pobierz, plaintext 
<?php
ReflectionClass::export('ErrorException');
?>
[PHP] pobierz, plaintext 

Funkcja __autoload() służy do automatycznego ładowania pliku.
Koledze chodzi właśnie o własne błęd z wyjątkami.
pozdrawiam

Ja drążę wypowiedź Krzystofa f. z ciekawym pomysłem.
Próbowałem go zastosować ale napotkalem na pewien problem:

[PHP] pobierz, plaintext 
<?php
 
public function handleError($sErrorCode, $sErrorMsg, $sErrorFile, $sErrorLine) {
 
		if(error_reporting() != 0) {
			throw new ErrorException($sErrorMsg, 0, $sErrorCode, $sErrorFile, $sErrorLine);
		} 
 
		return true;
 
	}
 
?>
[PHP] pobierz, plaintext 

gdy handleError wyrzuca wyjątek to wykonywanie metody się konczy, a poniewaz nie zwrocila true to nie jest wykonywany dalszy kod. Ma ktoś pomysl jak to obejść?

Co ty chcesz obchodzic? Jak metoda wyrzuca wyjatek to nie moze jednoczesnie zwracac wartosci. Ta funkcja zamienia errory na wyjatki, ktore jest duzo prosciej obslugiwac. Obsluga wyjatkow + wyjatki oddziela obsluge "bledow" aplikacji o jej normalnego kodu. Nie musisz zwracac wartosci np. -1, NULL gdy nastapi jakis blad, tylko wyrzucach wyjatek i go lapiesz. Unikasz wielu zagniezdzonych ifow ktore testuja wynik funkcji na obecnosc bledow. Jak poznasz dobrze wyjatki to zobaczysz, ze nie bedziesz bez nich mogl zyc (no dobra -- chociaz pisac ).

bonzo, nie zrozumiałeś problemu. Wszystko od trzeciego zdania praktycznie nie wnosi nic do dyskusji i co więcej opiera się na błędnym założeniu.

Podejrzewam, że tylko krzychu zaczaci o czym myslę;)
W obecnej postaci ten sposób jest nie do zaakceptowania, ponieważ zatrzymuje egzekucję kodu po błędzie pomimo tego, że wyjątek został obslużony przez handleException (zatrzymuje go handleError).

I kod powinien być zatrzymany. Jeśli masz błąd w aplikacji, to jaki jest cel dalszej egzystencji uruchamiania strony ?

A co do wzracania true. Jeżeli nie ma błędu, lub error_reporting nie jest ustawiony, wtedy moteda nie jest używana, czyli wzraca true.

Ozzy: Maual sie klania - http://pl.php.net/manual/en/function.set-e...ion-handler.php


Wg. mnie exception handler nie powinien byc w ogole uzywany - wyrzucane wyjatki trzeba lapac i obslugiwac w kodzie programu. Przeciez brak polaczenia z baza nie powinien zamykac aplikacji -- przeciez mozna np. content wczytac z cache'u w plikach.

Hmmm, a ktore to bledne zalozenie?

to prawda -- tak dzialaja wyjatki.

ktory dalszy kod? ten po wywolaniu funkcji ktora wyrzucila error, co spowodowalo wywolanie error_handlera?
A jak lapiesz ten wyjatek? Przechwytujesz go exc. handlerem?

W ogóle nie rozumiecie jaki jest problem, spróbujcie napisać to u siebie i sprawdzić jak działa...

W tej postaci jakiej jest, nawet niezłapany NOTICE zatrzymuje całą aplikację, co więcej, try trzeba by było robić dla kazdej linijki, ponieważ każdy nieobslużony błąd powodowalby zatrzymanie aplikacji, a zwykly błąd nie powoduje zatrzymania i nie powinien.
A taki jest Ociu sens, że większośc aplikacji potrafi się wykonać nawet gdy wystąpi błąd i nie powinna być zatrzymana.

Jak dla mnie cała koncepcja zamiany błędów na wyjątki w tej postaci jest błędna i ma więcej wad niż zalet. Nie widze dla niej zastosowania.

Bo trzeba go lapac! Nie try dla kazdje linijki - bo to nie sa errory tylko wyjatki - mozesz blokiem try objec wieksza ilosc kodu.

Dodaj do kodu krzysztofa

[PHP] pobierz, plaintext 
<?php
try
{
	set_error_handler( array( new ErrorHandler(), 'handleError' ) );
	$x = file_get_contents( 'aaaa' );
	echo 'kontynuujemy';
}
catch ( Exception $e )
{
	print( 'no i zlapalismy wyjatek: ' . $e->getMessage() . '<br />' );
	print( 'mozemy kontynuowac pisanie kodu...' );
}
?>
[PHP] pobierz, plaintext 

i zobacz jak to dziala.

No to powodzenia w łapaniu każdego błędu.

Juz nie wiem jak ci wytluamczyc obsluge wyjatkow - dorwij kilka tutoriali, ksiazek, poczytaj, popatrz z na kod z wyjatkami...

Tu http://northslope.lap.pl/dev/jaco/wyjatki.phps jest przykladowy kod (nie dzialjacy!) prezentujacy wyjatki i ich oblsuge.

Easy guys... Proszę Was, taka dyskusja do niczego nie prowadzi.
Jak zwykle każdy ma trochę racji i wszystko da się rozwiązać, ale po kolei.



Tak ale jej wykorzystanie do niczego nie prowadzi w tym konkretnym przypadku. Funkcja ta jest wywoływana w przypadku kiedy nie została znaleziona definicja klasy, a nie dołączany plik.



No jakby nie było. A ta skąd się wzięła? Ktoś wie gdzie jest jej definicja? Swoją drogą kolejny przykład, który utwierdza mnie w przekonaniu, że brak przestrzeni nazw w php jest dużym minusem i powinny się pojawić w 6.



Jest to prawdę mówiąc dobra uwaga. Mój przykład wygląda tak, ponieważ osobiście mam bardzo restrykcyjne podejście do błędów. Staram się z takim samym naciskiem eliminować błędy typu fatal jak i notice. Myślę że takie podejście się sprawdza, ale rzeczywiście php w stosunku do pewnych błędów zachowuje się inaczej i pozwala aby wykonywanie kodu było kontynuowane.

Decydując się na wyjątki w pewnym sensie zrezygnowaliśmy z takiej możliwości. Czy to źle? czy dobrze? ..tutaj każdy będzie miał swoje zdanie.

Spróbujmy zrobić mały refactoring, aby rozwiązać problem jaki ma Ozzy.
Po pierwsze wyrzucając wyjątek w bloku try, nie mamy możliwości kontynuowania kodu w tymże bloku. Aplikacja będzie działać dalej, przechodząc do odpowiedniego bloku catch. Więc będziemy musieli zrezygnować z bloku try (tam gdzie nie jest konieczne jego używanie) i polegać na funkcji set_exception_handler.

Potrzebna zmiana dotyczy metody ErrorHandler::handleError()

[PHP] pobierz, plaintext 
<?php
   public function handleError( $iErrNo, $sErrStr, $sErrFile, $sErrLine )
   {
	  set_exception_handler( array( $this, 'handleException' ) );
 
	  if ( error_reporting() != 0 )
	  {
		 if ($iErrNo & (E_NOTICE | E_USER_NOTICE)) {
			$this->handleException( new NoticeErrorException( $sErrStr, $iErrNo, $sErrFile, $sErrLine ) );
		 } else if ($iErrNo & (E_WARNING | E_USER_WARNING | E_CORE_WARNING | E_COMPILE_WARNING)) {
			$this->handleException( new WarningErrorException( $sErrStr, $iErrNo, $sErrFile, $sErrLine ) );
		 } else if ($iErrNo & (E_ERROR | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR)) {
			throw new FatalErrorException( $sErrStr, $iErrNo, $sErrFile, $sErrLine ); 
		 } else {
			throw new UnknownErrorException( $sErrStr, $iErrNo, $sErrFile, $sErrLine );
		 }
		 
	  } 
   }
?>
[PHP] pobierz, plaintext 

Teraz np. kod

[PHP] pobierz, plaintext 
<?php
set_error_handler( array( new ErrorHandler(), 'handleError' ) );
include 'wrong_file.inc.php';
echo 'Kolejne instrukcje';
 
?>
[PHP] pobierz, plaintext 

wykona się w całości. Natomiast ten

[PHP] pobierz, plaintext 
<?php
set_error_handler( array( new ErrorHandler(), 'handleError' ) );
trigger_error( 'Błąd', E_USER_ERROR );
echo 'Kolejne instrukcje';
 
?>
[PHP] pobierz, plaintext 

z wiadomych przyczyn nie.

Jeśli spodziewalibyśmy się jakiegoś konkretnego wyjątku, który wymaga obsłużenia należałoby oczywiście bezwzględnie zamknąć taki kod w bloku try.

No i pięknie. Jak widać jest to możliwe:)
Jak będę miał trochę czasu to napiszę prototyp i potestuję, ale pomysł wydaje się jak najbardziej działający.
Na użycie operatora bitowego też bym nie wpadł

Dzięki Krzysiek:)

Jedno pytanie jeszcze: dlaczego set_exception_handler jest w handleError, a nie na przykład w konstruktorze?
Przy kilku błędach będzie kilkakrotnie wywoływana, czyż nie?

ErrorException został wprowadzony do SPL od php 5.1 i na razie nie ma go w dokumentacji, jedynie w Reflection API.
Nawet buga raportowałem, bo był jeszcze niedopracowany:)

Jest też możliwość korzystania z obydwu zalet, tzn. z bloku try i "cichego" radzenia sobie z błędem - można utworzyć publiczną metodę klasy ErrorHandler, która zmieniałaby zachowanie metody handleError, raz wyrzucając wyjątek, a raz wywołując handleException...