Trudną częścią tego była uparta odmowa przeglądarki ujawniania jakiejkolwiek formy komunikatu o błędzie. Kiedy tak się dzieje, lubię przejść do wiersza poleceń i spróbować, eliminując w ten sposób serwer sieciowy jako zmienną.
Z czatu dowiedzieliśmy się, że wiersz poleceń wyświetlał błąd zgodnie z oczekiwaniami, ale nie zrobił tego z wdziękiem:błąd został wyświetlony, a skrypt został zatrzymany. To poważna awaria, której nie można przypisać serwerowi WWW.
Wraz z wprowadzeniem \Throwable , scenariusze, w których PHP umiera ciężko, stają się coraz rzadsze. Tak więc, aby złapać ostatni oddech PHP, zaimplementowaliśmy register_shutdown_function który ściągnął error_get_last próbując dowiedzieć się, co, jeśli w ogóle, zostało powiedziane tuż przed wybuchem.
To ujawniło krótko komunikat o błędzie w przeglądarce (tym razem przy użyciu innej przeglądarki). Nie było to jednak powtarzalne. W tym momencie wglądem było buforowanie:composer dump-autoload naprawiono problem!
Podejrzewam, że stało się tak:
Eloquentrzucił wyjątek- PHP bulgotał przez klasy obsługi wyjątków Laravela
- W pewnym momencie PHP próbowało załadować klasę, której nie było w autoloaderze
- PHP uległ poważnej awarii (jest to jeden z tych przypadków, w których PHP 7.0 zwalnia)
Uruchamiając composer dump-autoload , wszystkie „brakujące” klasy zostały przeniesione do obszaru działania autoloadera i przy kolejnej próbie wystąpiła poprawna sekwencja kodu.
