spl-Autoloader und die lieben Exceptions

nikosch · 06.12.2011, 19:06

Moin,

ich bastle mal wieder am Autoloader. Ich finde ja das Konzept von spl super, mehrere unabhängige Autoloader-Callbacks registrieren zu können. Gerade weil ich Name-to-Path-basierte Loader nicht mag. Nur suche ich immer noch nach einer Möglichkeit, Fehlschläge per Exception, statt mit einem fatal error handhaben zu können. In einem einzelnen Autoloader kann man selbstredend diese Exception nicht werfen, weil dann die nachfolgenden nicht mehr geprüft werden. Umleiten der Fehlerausgabe generell auf Exceptions finde ich auch nicht sonderlich elegant.
Da SPL im Ggs. zum klassischen __autoload keine zentrale Loader-Instanz besitzt (oder?), gibts ja keinen Ort, nach Durchlaufen aller Callbacks die Exception zu werfen.

Wie löst Ihr das?

Ich hatte jetzt eine Idee, habe aber noch nicht tiefer evaluiert, wie brauchbar das ist. Was haltet Ihr davon?:

Code-Basis:

PHP-Code:

  <?php
// Die exemplarischen Autoloader

function al_one ()
  {
  ?>autoloader one<br><?php
  }

function al_two ()
  {
  ?>autoloader two<br><?php
  }

function al_three ()
  {
  ?>autoloader three<br><?php
  }

// Registrierung

spl_autoload_register ('al_one');
spl_autoload_register ('al_two');
spl_autoload_register ('al_three');

new Foo; // fatal error

Ansatz:

PHP-Code:

  // Die exemplarischen Autoloader
// …

// Dummy-Callback zum Werfen der Exception

function al_dummy ($sClass)
  {
  throw new Exception ('not found: ' . $sClass);
  }

// Registrierscript. Sorgt dafür, dass Exception-Loader immer als letzter
// im Stack steht


function add_autoloader ($mCallback)
  {
  spl_autoload_unregister ('al_dummy');
  spl_autoload_register ($mCallback);
  spl_autoload_register ('al_dummy');
  }

// angepasste Registrierung

add_autoloader ('al_one');
add_autoloader ('al_two');
add_autoloader ('al_three');

new Foo; // Fatal error: Uncaught exception 'Exception' with message 'not found: Foo'

PHP-Code:

  // Funktioniert sogar, wenn nicht alle Registrierungen über den eigenen Loader laufen. Hauptsache der letzte tuts.
add_autoloader ('al_one');
spl_autoload_register ('al_two');

add_autoloader ('al_three');

Das Ganze klappt wegen der Exception natürlich nur ab 5.3.0+.

Ergänzungsfrage: Weiß irgend jemand, was der throw-Parameter im spl_autoload_register bewirken soll? Ich finde kein Beispiel, das hier irgendeinen Unterschied zwischen TRUE und FALSE-Setting offenbart.

Dark Guardian · 06.12.2011, 19:31

Das Handbuch sagt doch alles zum throw Parameter.

http://php.net/manual/de/function.sp...d-register.php

Das "Hinten Anhängen" brauchst du auch nicht da spl_autoload_register eine neue Callback Funktion auch an den Anfang des Stacks setzen kann. (prepend Parameter).

nikosch · 06.12.2011, 19:40

Zitat:

Das Handbuch sagt doch alles zum throw Parameter.

http://php.net/manual/de/function.sp...d-register.php

Sag mal bin ich blöde? Hab ich das jedesmal falsch gelesen, bzw. falsch interpretiert?! Danke, ist klar geworden.

Zitat:

Das "Hinten Anhängen" brauchst du auch nicht da spl_autoload_register eine neue Callback Funktion auch an den Anfang des Stacks setzen kann. (prepend Parameter).

Auch dafür danke, guter Hinweis, Exceptions sind ja ohnehin erst ab 5.3 verfügbar. Da geht das ja Hand in Hand. Da würde ich dann den Registrierer so aufbohren, falls man dann doch mal aus Performance-oder-was-auch-immer-für-Gründen append nutzen will:

PHP-Code:

  function add_autoloader ($mCallback , $bPrepend = true)
  {
  if (true == $bPrepend)
    {
    spl_autoload_register ($mCallback , true , true);
    }
  else
    {
    spl_autoload_unregister ('al_dummy');
    spl_autoload_register ($mCallback);
    spl_autoload_register ('al_dummy');
    }
  }

[edit]

In diesem Fall muss man aber einmalig den Exception-werfenden Callback registrieren. Ich glaube ich bleibe doch bei der alten Lösung.

nikosch · 07.12.2011, 02:02

Also jetzt mal ehrlich, was für eine ätzende Logik haben sie denn da eingebaut:

PHP-Code:

 
<pre><?php



// Die exemplarischen Autoloader

function al_one ($sClass)
  {
  ?>autoloader one <?php echo $sClass , '<br>';
  throw new Exception ('one not found: ' . $sClass);
  }

function al_two ($sClass)
  {
  ?>autoloader two <?php echo $sClass , '<br>';
  throw new Exception ('two not found: ' . $sClass);
  }

function al_three ($sClass)
  {
  ?>autoloader three <?php echo $sClass , '<br>';
  $func = 'create' . $sClass;
  $func ();
  }



spl_autoload_register ('al_one');
spl_autoload_register ('al_two');
spl_autoload_register ('al_three');




function createFoo ()
  {
  class Foo extends Bar {}
  }

function createBar ()
  {
  class Bar {}
  }



new Foo;

Code:

autoloader one Foo
autoloader two Foo
autoloader three Foo
autoloader one Bar
autoloader two Bar
autoloader three Bar



Fatal error:  Uncaught exception 'Exception' with message 'one not found: Foo' in W:\test4.php:10
Stack trace:
#0 [internal function]: al_one('Foo')
#1 W:\test4.php(47): spl_autoload_call('Foo')
#2 {main}

Next exception 'Exception' with message 'two not found: Foo' in W:\test4.php:16
Stack trace:
#0 [internal function]: al_two('Foo')
#1 W:\test4.php(47): spl_autoload_call('Foo')
#2 {main}

Next exception 'Exception' with message 'one not found: Bar' in W:\test4.php:10
Stack trace:
#0 [internal function]: al_one('Bar')
#1 W:\test4.php(37): spl_autoload_call('Bar')
#2 W:\test4.php(22): createFoo()
#3 [internal function]: al_three('Foo')
#4 W:\test4.php(47): spl_autoload_call('Foo')
#5 {main}

Next exception 'Exception' with message 'two not found: Bar' in W:\test4.php:16
Stack trace:
#0 [internal function]: al_two('Bar')
#1 W:\test4.php(37): spl_autoload_call('Bar')
#2 W:\test4.php(22): createFoo()
#3 [internal function]: al_three('Foo')
#4 W:\test4.php(47): spl_autoload_call('Foo')
#5 {main}
  thrown in W:\test4.php on line 16

createXY repräsentieren mal die Autoload-Includes. Der Autoloader durchläuft die registrierten Autoloader, führt Vererbungslogik geladener Klassen aus, ignoriert aber sammelt die Exceptions als Chain nur um dann am Ende zu behaupten die ursprüngliche Klasse konnte nicht aufgelöst werden, obwohl er deren Elternklasse selbst noch angefordert hat?! Wer denkt sich solchen Hirnriss aus?!! Da kann man debuggen bis der Arzt kommt, wenn irgendwo ne Exception geworfen wird.

[edit]

Noch geiler ist nur das:

PHP-Code:

  //new Foo;
Foo::dss();

Code:

autoloader one Foo
autoloader two Foo
autoloader three Foo
autoloader one Bar
autoloader two Bar
autoloader three Bar


Fatal error:  Class 'Foo' not found in W:\test4.php on line 47

Seriously?

mermshaus · 07.12.2011, 08:10

Zitat:

Zitat von nikosch

Umleiten der Fehlerausgabe generell auf Exceptions finde ich auch nicht sonderlich elegant.

Geht auch bei fatal errors (E_ERROR) nicht. Jedenfalls nicht mit set_error_handler. Das beantwortet auch schon so ziemlich die Frage, wie ich das löse…

Zitat:

Da SPL im Ggs. zum klassischen __autoload keine zentrale Loader-Instanz besitzt (oder?), gibts ja keinen Ort, nach Durchlaufen aller Callbacks die Exception zu werfen.

Das sehe ich auch so.

Zitat:

Wie löst Ihr das?

Gar nicht. Das Handbuch sagt zu Fehlern der Kategorie E_ERROR:

Zitat:

Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted.

Ich rede mir ein, das als Designentscheidung der PHP-Entwickler werten zu können, gegen die ich nicht vorgehen kann/sollte. Ähnlich ist es vielleicht bei den require*-Befehlen, die ebenfalls zu fatal errors führen. Etwas, das unbedingt benötigt wird, hat nicht geklappt, und mein Programm ist nun in einem so unkontrollierbaren Zustand, dass weitere Ausführung keinen Sinn mehr ergibt.

Das ist etwas stumpf argumentiert, aber ich habe halt auch nicht entschieden, dass eine fehlende Klasse E_ERROR ist und dass ich diese Fehler nicht aufhalten kann. (Edit: Wobei das natürlich auch nichts daran ändern würde, dass im Zweifel wohl die gesamte Fehlerbehandlung per set_error_handler global umgeschrieben werden müsste. Es gibt einfach keine Hooks, in die man eigenen Code einklinken könnte.)

Wenn's nicht kritisch ist, könnte die Instantiierung in eine class_exists-Bedingung geschrieben werden (klappert die Autoloader ab). Also, es könnte/müsste/würde/sollte irgendwie drumrum programmiert werden. (Ich schätze, an der Formulierung sieht man, dass ich das auch alles nicht so 100 % nachvollziehbar finde…)

Noch mehr Getrickse:

PHP-Code:

  <?php

function al_one ($sClass)
  {
  ?>autoloader one <?php echo $sClass , '<br>';

  eval("class $sClass { public function __construct() { throw new Exception('$sClass not found'); } }");

  }

mquadrat · 07.12.2011, 09:52

Die non-recoverable errors sind halt die Entsprechung zu Design-Time-Fehlern in compilierten Sprachen. Ein <Bitte Sprache nach Wunsch hier einsetzen> Programm kriegst du ja auch nicht compiliert, wenn eine Klasse fehlt.

Ich könnte mir zumindest vorstellen, dass sie das im Sinn hatten

zwutz · 07.12.2011, 13:45

könnte man die Überprüfung nicht mit pcntl_fork auslagern? Wenn das durch nen Fatal abbricht, bricht der parent wenigstens nicht ab.

tr0y · 07.12.2011, 15:07

Meines erachtens geht das nur indem du eine art Garbage Loader anfügst, der mit aliase umsich wirft, oder du Klopfst auf dem error_handler rum. Ersteres ist je nach Applikationsaufbau ( wenn man die Volle gewalt über die Anwendungsentwicklung hat und nichts umbaut ) allerdings einfacher und logischer zu basteln:

PHP-Code:

  <?php

class autoLoadException extends Exception {

   public $classname;

   public function __construct( $classname, $message, $code = 0, &$last = null ) {
      parent::__construct($message, $code, $last );
      
      $this->classname = $classname;
   }

}

class nullClass extends stdClass {

}

class autoLoadMaintainer {

    protected static $_exceptions = array();

    public static function addException ( Exception $e ) {
       self::$_exceptions[] = $e;
       
       return true;
    }
    
    public static function getExceptions() {
       return self::$_exceptions;
    }

}

spl_autoload_register( function ( $class ) {

    class_alias('nullClass', $class);

    return autoLoadMaintainer::addException(
       new autoLoadException( $class, 'Class not found' )
    );

} );

new foo;
new bar;
new baz;

var_dump( autoLoadMaintainer::getExceptions() );

nikosch · 07.12.2011, 17:32

Danke für die Meldungen. Es geht auch nicht darum, fehlende Klassen noch irgendwie auszugleichen, sondern die Applikation an einem zentralen Punkt sinnvoll zu beenden. Gerade wenn man Bibliotheken dynamisch als Module nachlädt finde ich es recht sinnvoll, den Ladevorgang noch kontrollieren zu können. Und die klassische weiße Seite finde ich jetzt nicht so prall.

Zitat:

Noch mehr Getrickse:

Hab ich im Manual auch gesehen. Da kann ich mich aber nicht mit anfreunden. Zumal das aufs selbe rausläuft, ein solcher Autoloader müsste ja zwingend immer der letzte in der Queue sein.

Zitat:

könnte man die Überprüfung nicht mit pcntl_fork auslagern?

Ich glaube, da steige ich aus.

Also ich probier mal heute noch ein bissl rum. Danke für die Meinungen.

mermshaus · 07.12.2011, 20:47

Zitat:

Zitat von nikosch

Es geht auch nicht darum, fehlende Klassen noch irgendwie auszugleichen, sondern die Applikation an einem zentralen Punkt sinnvoll zu beenden.

Es gäbe noch register_shutdown_function. Die Preisfrage ist eben, ob die Anwendung dann überhaupt noch sinnvoll zu beenden ist oder ob vielleicht gerade eine Klasse fehlt, die in der Shutdown-Function benötigt wird.

Zitat:

Gerade wenn man Bibliotheken dynamisch als Module nachlädt finde ich es recht sinnvoll, den Ladevorgang noch kontrollieren zu können.

Da könntest du entweder den Modul-Autoloader so schreiben, dass er entscheiden kann, dass er für das Laden einer bestimmten Klasse zuständig ist (siehe eval-Lösung – Vorsicht aber vor Classname-Injection-Attacken

), oder im Ladevorgang des Moduls etwas in folgender Art machen (Umriss):

PHP-Code:

  function loadModule($moduleClassList)
{
    if (file_exists($moduleClassList)) {
        $classes = file($moduleClassList);

        foreach ($classes as $class) {
            if (!class_exists($class)) {
                /* throw */
            }
        }
    } else {
        /* throw */
    }
}

Zitat:

Hab ich im Manual auch gesehen. Da kann ich mich aber nicht mit anfreunden. Zumal das aufs selbe rausläuft, ein solcher Autoloader müsste ja zwingend immer der letzte in der Queue sein.

Du müsstest klar definieren, dass eine Klasse von einem bestimmten Autoloader abgehandelt werden muss (durch Namespace-Präfix oder so). Dann kann der Autoloader in der Queue an jeder Stelle auftauchen. Eine ganz allgemeine Lösung ist das aber nicht, nein.

PHP-Code:

  <?php

error_reporting(-1);
ini_set('display_errors', true);

spl_autoload_register(function ($class) {
    echo '*************** first loader called', "\n";

    // Wenn nicht $class.inc existiert und $class von diesem Loader verwaltet
    // werden soll, dann...

    eval("class $class {
            function __construct() { throw new Exception('$class not found'); }
    }");

    return true; // Wird durch Existenz der Klasse nun aber offenbar auch
                 // impliziert
});

spl_autoload_register(function ($class) {
    echo '*************** this won\'t be reached', "\n";
});



class Foo extends Bar {}

new Foo('bar', 'baz');

Code:

*************** first loader called
PHP Fatal error:  Uncaught exception 'Exception' with message 'Bar not found' in /home/marc/w/nb/x.php(14) : eval()'d code:2
Stack trace:
#0 /home/marc/w/nb/x.php(28): Bar->__construct('bar', 'baz')
#1 {main}
  thrown in /home/marc/w/nb/x.php(14) : eval()'d code on line 2

Fatal error: Uncaught exception 'Exception' with message 'Bar not found' in /home/marc/w/nb/x.php(14) : eval()' in /home/marc/w/nb/x.php(14) : eval()'d code on line 2

Exception: Bar not found in /home/marc/w/nb/x.php(14) : eval()'d code on line 2

Call Stack:
    0.0003     329788   1. {main}() /home/marc/w/nb/x.php:0
    0.0006     334244   2. Bar->__construct() /home/marc/w/nb/x.php:28

Zitat:

Zitat von tr0y

wenn man die Volle gewalt über die Anwendungsentwicklung hat und nichts umbaut

Wenn wir von dem Fall ausgehen, tut es auch ein Exception-werfender Autoloader an letzter Stelle der Queue. Aber das halte ich für sehr unflexibel. (Wobei auch das so eine Frage ist… Was können wir als Entwickler der Anwendung einfach so vorschreiben, was nicht? An irgendeiner Stelle müssen wir anfangen, davon auszugehen, dass Modulautoren oder andere Programmierer keinen Mist bauen. Wenn sie dennoch Mist bauen, ist sowieso Mist. http://www.phpforum.de/forum/showpos...73&postcount=3)

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Autoloader	Phantomias	PHP Einsteiger	6	07.08.2011 14:59
[Erledigt] Update Zend Autoloader BasePath per Application.ini mitgeben	dreamcatcher	PHP Einsteiger	6	15.06.2011 18:00
Server führt Skript bei Verwendung von Exceptions nicht aus	Tidus	PHP Tipps 2010	10	22.04.2010 11:28
PHPUnit Exceptions	Chriz	PHP Tipps 2010	7	08.03.2010 16:54
Praktische Anwendung von Exceptions	chunky	PHP Tipps 2010	6	17.02.2010 21:00
[Erledigt] Zend_Framework: Autoloader lädt Klasse nicht wie erwartet	christophk	PHP Tipps 2009	5	16.01.2010 08:10
[Erledigt] Autoloader und einbinden von PEAR-Klasse	Daniel86	PHP-Fortgeschrittene	2	02.09.2009 15:12
Exceptions, strukturelle Systematik	nikosch	Software-Design	9	10.08.2009 23:10
[Erledigt] [ZF 1.8.0] Der neue Autoloader, Modifizierungen?	#EFEFEF	PHP-Fortgeschrittene	11	27.06.2009 01:10
Exceptions dateiübergreifend abfangen?	dauerbaustelle	PHP-Fortgeschrittene	1	04.06.2009 15:00
Frage zu try, throw und exceptions	litterauspirna	PHP Tipps 2009	6	17.05.2009 14:21
PHP: Exceptions - Teil 2	Zergling-new	Tutorials	5	15.03.2009 11:00
PHP: Exceptions - Teil 1	Zergling-new	Tutorials	4	05.12.2007 23:31
PHP-Errors zu exceptions	brian johnson	PHP-Fortgeschrittene	6	06.11.2007 12:45
erbende Exceptions mit PHP 5.1.1 nicht mehr möglich?	HStev	PHP-Fortgeschrittene	4	27.01.2006 14:32

06.12.2011, 19:06
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	spl-Autoloader und die lieben Exceptions Moin, ich bastle mal wieder am Autoloader. Ich finde ja das Konzept von spl super, mehrere unabhängige Autoloader-Callbacks registrieren zu können. Gerade weil ich Name-to-Path-basierte Loader nicht mag. Nur suche ich immer noch nach einer Möglichkeit, Fehlschläge per Exception, statt mit einem fatal error handhaben zu können. In einem einzelnen Autoloader kann man selbstredend diese Exception nicht werfen, weil dann die nachfolgenden nicht mehr geprüft werden. Umleiten der Fehlerausgabe generell auf Exceptions finde ich auch nicht sonderlich elegant. Da SPL im Ggs. zum klassischen __autoload keine zentrale Loader-Instanz besitzt (oder?), gibts ja keinen Ort, nach Durchlaufen aller Callbacks die Exception zu werfen. Wie löst Ihr das? Ich hatte jetzt eine Idee, habe aber noch nicht tiefer evaluiert, wie brauchbar das ist. Was haltet Ihr davon?: Code-Basis: PHP-Code: `<?php // Die exemplarischen Autoloader function al_one () { ?>autoloader one<br><?php } function al_two () { ?>autoloader two<br><?php } function al_three () { ?>autoloader three<br><?php } // Registrierung spl_autoload_register ('al_one'); spl_autoload_register ('al_two'); spl_autoload_register ('al_three'); new Foo; // fatal error` Ansatz: PHP-Code: // Die exemplarischen Autoloader // … // Dummy-Callback zum Werfen der Exception function al_dummy ($sClass) { throw new Exception ('not found: ' . $sClass); } // Registrierscript. Sorgt dafür, dass Exception-Loader immer als letzter // im Stack steht function add_autoloader ($mCallback) { spl_autoload_unregister ('al_dummy'); spl_autoload_register ($mCallback); spl_autoload_register ('al_dummy'); } // angepasste Registrierung add_autoloader ('al_one'); add_autoloader ('al_two'); add_autoloader ('al_three'); new Foo; // Fatal error: Uncaught exception 'Exception' with message 'not found: Foo' PHP-Code: `// Funktioniert sogar, wenn nicht alle Registrierungen über den eigenen Loader laufen. Hauptsache der letzte tuts. add_autoloader ('al_one'); spl_autoload_register ('al_two'); add_autoloader ('al_three');` Das Ganze klappt wegen der Exception natürlich nur ab 5.3.0+. Ergänzungsfrage: Weiß irgend jemand, was der throw-Parameter im spl_autoload_register bewirken soll? Ich finde kein Beispiel, das hier irgendeinen Unterschied zwischen TRUE und FALSE-Setting offenbart. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

06.12.2011, 19:31
Dark Guardian Erfahrener Benutzer Registriert seit: 10.10.2009 Beiträge: 2.631 PHP-Kenntnisse: Fortgeschritten	Das Handbuch sagt doch alles zum throw Parameter. http://php.net/manual/de/function.sp...d-register.php Das "Hinten Anhängen" brauchst du auch nicht da spl_autoload_register eine neue Callback Funktion auch an den Anfang des Stacks setzen kann. (prepend Parameter). __________________ "Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

07.12.2011, 02:02
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Also jetzt mal ehrlich, was für eine ätzende Logik haben sie denn da eingebaut: PHP-Code: <pre><?php // Die exemplarischen Autoloader function al_one ($sClass) { ?>autoloader one <?php echo $sClass , '<br>'; throw new Exception ('one not found: ' . $sClass); } function al_two ($sClass) { ?>autoloader two <?php echo $sClass , '<br>'; throw new Exception ('two not found: ' . $sClass); } function al_three ($sClass) { ?>autoloader three <?php echo $sClass , '<br>'; $func = 'create' . $sClass; $func (); } spl_autoload_register ('al_one'); spl_autoload_register ('al_two'); spl_autoload_register ('al_three'); function createFoo () { class Foo extends Bar {} } function createBar () { class Bar {} } new Foo; Code: autoloader one Foo autoloader two Foo autoloader three Foo autoloader one Bar autoloader two Bar autoloader three Bar Fatal error: Uncaught exception 'Exception' with message 'one not found: Foo' in W:\test4.php:10 Stack trace: #0 [internal function]: al_one('Foo') #1 W:\test4.php(47): spl_autoload_call('Foo') #2 {main} Next exception 'Exception' with message 'two not found: Foo' in W:\test4.php:16 Stack trace: #0 [internal function]: al_two('Foo') #1 W:\test4.php(47): spl_autoload_call('Foo') #2 {main} Next exception 'Exception' with message 'one not found: Bar' in W:\test4.php:10 Stack trace: #0 [internal function]: al_one('Bar') #1 W:\test4.php(37): spl_autoload_call('Bar') #2 W:\test4.php(22): createFoo() #3 [internal function]: al_three('Foo') #4 W:\test4.php(47): spl_autoload_call('Foo') #5 {main} Next exception 'Exception' with message 'two not found: Bar' in W:\test4.php:16 Stack trace: #0 [internal function]: al_two('Bar') #1 W:\test4.php(37): spl_autoload_call('Bar') #2 W:\test4.php(22): createFoo() #3 [internal function]: al_three('Foo') #4 W:\test4.php(47): spl_autoload_call('Foo') #5 {main} thrown in W:\test4.php on line 16 createXY repräsentieren mal die Autoload-Includes. Der Autoloader durchläuft die registrierten Autoloader, führt Vererbungslogik geladener Klassen aus, ignoriert aber sammelt die Exceptions als Chain nur um dann am Ende zu behaupten die ursprüngliche Klasse konnte nicht aufgelöst werden, obwohl er deren Elternklasse selbst noch angefordert hat?! Wer denkt sich solchen Hirnriss aus?!! Da kann man debuggen bis der Arzt kommt, wenn irgendwo ne Exception geworfen wird. [edit] Noch geiler ist nur das: PHP-Code: `//new Foo; Foo::dss();` Code: autoloader one Foo autoloader two Foo autoloader three Foo autoloader one Bar autoloader two Bar autoloader three Bar Fatal error: Class 'Foo' not found in W:\test4.php on line 47 Seriously? __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

07.12.2011, 09:52
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.019 PHP-Kenntnisse: Fortgeschritten	Die non-recoverable errors sind halt die Entsprechung zu Design-Time-Fehlern in compilierten Sprachen. Ein <Bitte Sprache nach Wunsch hier einsetzen> Programm kriegst du ja auch nicht compiliert, wenn eine Klasse fehlt. Ich könnte mir zumindest vorstellen, dass sie das im Sinn hatten __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

07.12.2011, 13:45
zwutz Erfahrener Benutzer Registriert seit: 04.08.2010 Beiträge: 287 PHP-Kenntnisse: Fortgeschritten	könnte man die Überprüfung nicht mit pcntl_fork auslagern? Wenn das durch nen Fatal abbricht, bricht der parent wenigstens nicht ab.

07.12.2011, 15:07
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	Meines erachtens geht das nur indem du eine art Garbage Loader anfügst, der mit aliase umsich wirft, oder du Klopfst auf dem error_handler rum. Ersteres ist je nach Applikationsaufbau ( wenn man die Volle gewalt über die Anwendungsentwicklung hat und nichts umbaut ) allerdings einfacher und logischer zu basteln: PHP-Code: <?php class autoLoadException extends Exception { public $classname; public function __construct( $classname, $message, $code = 0, &$last = null ) { parent::__construct($message, $code, $last ); $this->classname = $classname; } } class nullClass extends stdClass { } class autoLoadMaintainer { protected static $_exceptions = array(); public static function addException ( Exception $e ) { self::$_exceptions[] = $e; return true; } public static function getExceptions() { return self::$_exceptions; } } spl_autoload_register( function ( $class ) { class_alias('nullClass', $class); return autoLoadMaintainer::addException( new autoLoadException( $class, 'Class not found' ) ); } ); new foo; new bar; new baz; var_dump( autoLoadMaintainer::getExceptions() ); __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr. Geändert von tr0y (07.12.2011 um 15:10 Uhr).