La parte difficile di questo è stata l'ostinato rifiuto del browser di rivelare qualsiasi forma di messaggio di errore. Quando ciò accade, mi piace andare alla riga di comando e provarlo, eliminando così il server web come variabile.
Dalla chat, abbiamo appreso che la riga di comando ha mostrato l'errore come previsto, ma non lo ha fatto con grazia:l'errore è stato emesso e lo script è stato interrotto. È un crash duro, non attribuibile al server web.
Con l'introduzione di \Throwable
, gli scenari in cui PHP è duro a morire stanno diventando sempre meno numerosi. Quindi, nel tentativo di trattenere l'ultimo respiro di PHP, abbiamo implementato una register_shutdown_function
che ha estratto error_get_last
nel tentativo di capire cosa, semmai, è stato detto poco prima di esplodere.
Questo ha rivelato, brevemente, il messaggio di errore nel browser (questa volta utilizzando un browser diverso). Tuttavia, questo non era ripetibile. L'intuizione a questo punto è stata la memorizzazione nella cache:composer dump-autoload
risolto il problema!
Sospetto che quello che è successo sia questo:
Eloquent
ha lanciato un'eccezione- PHP lo stava ribollendo attraverso le classi di gestione delle eccezioni di Laravel
- Ad un certo punto, PHP ha tentato di caricare una classe che non era nel caricatore automatico
- PHP è andato in crash (questo è uno di quei casi in cui PHP 7.0 è stato bloccato)
Eseguendo composer dump-autoload
, tutte le classi "mancanti" sono state portate nell'ambito del caricatore automatico e, quando si è tentato di nuovo, si è verificata la sequenza di codice corretta.