IX. Les erreurs et exceptions▲
IX-A. Erreurs▲
Le PHP a plusieurs niveaux de gravité pour les erreurs. Les trois types de messages d'erreurs les plus communs sont les erreurs, les avertissements et les remarques. Il existe différents niveaux de gravité : E_ERROR, E_WARNING et E_NOTICE. Les erreurs sont des erreurs d'exécution fatales et sont souvent causées par des bogues qui ont besoin d'être réglés étant donné qu'ils stoppent l'interprétation du reste du code. Les avertissements sont des erreurs non fatales, autrement dit l'exécution du script continuera. Les remarques sont des messages informatifs sur du code qui pourrait poser problème lors de l'exécution du script, cependant l'exécution ne sera pas arrêtée.
Il existe un autre type de message d'erreur qui se présente lors de la phase de compilation, c'est le message E_STRICT. Ces messages sont utilisés pour suggérer des changements dans votre code afin de s'assurer de la meilleure interopérabilité et de la meilleure compatibilité ascendante possible.
IX-B. Exceptions▲
Les exceptions sont une partie standardisée dans la plupart des langages de programmation populaires, mais elles sont souvent négligées par les programmeurs PHP. Les langages comme Ruby sont très fortement équipés pour gérer les exceptions ainsi, à chaque fois qu'une chose se passe mal comme l'échec d'une requête HTTP ou d'une requête à la BDD, Ruby (ou les « gems » utilisés) va lancer une exception à l'écran vous indiquant immédiatement qu'il y a eu une erreur.
Le PHP en lui-même est plutôt laxiste avec ce type d'erreur, ainsi un appel à file_get_contents() va généralement renvoyer un FALSE accompagné d'un avertissement. Beaucoup d'anciens frameworks PHP comme CodeIgniter vont juste retourner false, enregistrer un message dans leur fichier de log et peut-être vous laisser utiliser une méthode comme $this->upload->get_error() pour voir ce qu'il s'est mal passé. Le problème ici est que vous devez vous-même chercher l'erreur et vérifier dans la doc ce qu'elle signifie pour cette fonction au lieu de l'avoir rendue évidente à comprendre.
L'autre problème arrive lorsque les classes lancent automatiquement une erreur à l'écran et termine le processus. Si vous faites cela, un autre développeur ne sera plus capable de gérer cette erreur à l'exécution. Les exceptions devraient être lancées afin d'avertir le développeur qu'une chose ne s'est pas passée comme prévu, ça devrait être à eux de décider comment ils veulent gérer cela, par exemple :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
<?php
$email = new Fuel\Email;
$email->subject('Mon sujet');
$email->body('Comment allez-vous ?');
$email->to('guy@exemple.com', 'Un gars');
try
{
$email->send();
}
catch(Fuel\Email\ValidationFailedException $e)
{
// La validation a échoué
}
catch(Fuel\Email\SendingFailedException $e)
{
// Le pilote ne peut pas envoyer l'email
}
finally
{
// ce bloc est exécuté même si une exception a été générée et avant que l'exécution normale reprenne
}
IX-B-1. Les exceptions SPL▲
La classe générique Exception ne fournit pas un contexte intéressant pour le débogage. Pour remédier à cela, il est possible de créer une sous-classe du type générique Exception :
2.
<?php
class ValidationException extends Exception {}
Cela vous permet d'ajouter plusieurs blocs catch et de gérer les exceptions différemment. Cela peut conduire à la création de beaucoup de classes personnalisées qui auraient pu être évitées si les exceptions de la SPL avaient été utilisées avec l'extension SPL.
Si par exemple vous utilisez la méthode magique __call() et qu'une méthode invalide est demandée alors, au lieu de générer une exception standard vague ou d'utiliser une sous-classe personnalisée, vous pourriez tout simplement faire throw new BadFunctionCallException.
