La partie délicate de cela a été le refus obstiné du navigateur de révéler toute forme de message d'erreur. Lorsque cela se produit, j'aime aller à la ligne de commande et l'essayer, éliminant ainsi le serveur Web en tant que variable.
À partir du chat, nous avons appris que la ligne de commande affichait l'erreur comme prévu, mais ne l'a pas fait gracieusement :l'erreur a été générée et le script a été interrompu. Il s'agit d'un grave plantage, qui n'est pas attribuable au serveur Web.
Avec l'introduction de \Throwable , les scénarios où PHP a la vie dure deviennent de plus en plus rares. Donc, dans un effort pour rattraper le dernier souffle de PHP, nous avons implémenté une register_shutdown_function qui a tiré error_get_last dans le but de comprendre ce qui a été dit, le cas échéant, juste avant d'exploser.
Cela a révélé, brièvement, le message d'erreur dans le navigateur (cette fois en utilisant un navigateur différent). Cependant, ce n'était pas reproductible. L'insight à ce stade était la mise en cache :composer dump-autoload a résolu le problème !
Je suppose que ce qui s'est passé est ceci :
Eloquenta lancé une exception- PHP faisait bouillonner cela grâce aux classes de gestion des exceptions de Laravel
- À un moment donné, PHP a tenté de charger une classe qui n'était pas dans le chargeur automatique
- PHP s'est écrasé brutalement (c'est l'un de ces cas où PHP 7.0 tombe en panne)
En exécutant composer dump-autoload , toutes les classes "manquantes" ont été placées sous la responsabilité de l'autochargeur et, lors d'une nouvelle tentative, la séquence de code correcte s'est produite.
