Der knifflige Teil dabei war die hartnäckige Weigerung des Browsers, irgendeine Form von Fehlermeldungen anzuzeigen. Wenn das passiert, gehe ich gerne zur Befehlszeile und versuche es, wodurch der Webserver als Variable eliminiert wird.
Aus dem Chat erfuhren wir, dass die Befehlszeile den Fehler wie erwartet anzeigte, dies jedoch nicht ordnungsgemäß tat:Der Fehler wurde ausgegeben und das Skript wurde angehalten. Das ist ein harter Absturz, der nicht dem Webserver zuzuschreiben ist.
Mit der Einführung von \Throwable , werden die Szenarien, in denen PHP hart stirbt, immer seltener. In dem Bemühen, PHP den letzten Atemzug zu erwischen, haben wir eine register_shutdown_function implementiert das hat error_get_last gezogen um herauszufinden, was, wenn überhaupt, kurz vor der Explosion gesagt wurde.
Dies offenbarte kurz die Fehlermeldung im Browser (diesmal mit einem anderen Browser). Dies war jedoch nicht wiederholbar. Die Einsicht an dieser Stelle war das Caching:composer dump-autoload Problem behoben!
Ich vermute, dass Folgendes passiert ist:
Eloquenthat eine Ausnahme ausgelöst- PHP sprudelte das durch Laravels Ausnahmebehandlungsklassen hoch
- Irgendwann hat PHP versucht, eine Klasse zu laden, die nicht im Autoloader war
- PHP stürzte schwer ab (das ist einer der Fälle, in denen PHP 7.0 abstürzt)
Durch Ausführen von composer dump-autoload , wurden alle "fehlenden" Klassen in den Bereich des Autoloaders gebracht und bei einem erneuten Versuch wurde die richtige Codesequenz angezeigt.
