01-03-2015, 02:53 PM
Les exceptions, c'est aussi de la documentation implicite (qui a l'avantage de rester à jour, elle…).
Pour moi , les exceptions sont également un moyen d'éviter la programmation défensive en blindant le code de conditions. Ainsi, mon code métier ne fait pas ou peu de vérification sur ce qu'il reçoit : c'est au code appelant d'envoyer les bonnes choses. Ça permet de garder un code clair et focalisé sur un rôle propre ; les conditions ayant tendance à proliférer. En revanche, si quelque chose se passe mal, je veux que mon code explose vite (Fail fast), pour prendre (ou non) des mesures.
Avec des exceptions dédiés (souvent je sous-classe juste StandardError) qui portent un nom sans ambiguité (GameAlreadyStarted, CharacterAlreadyDead, …) je sais tout de suite ce qui se passe (aussi bien sur le moment que quand je lis mes logs) et je peux catcher cette erreur seulement au plus au point si ça me chante (les fameux messages de type "L'application a rencontré une erreur, nos équipes ont été notifiées.") ou bien la prendre en charge plus proche de son appel pour tenter une remédiation.
Couplé à des outils de type error catcher (comme Airbrake (service) ou Errbit (self-hosted), qui ont un client pour PHP), ça permet de documenter et de monitorer ton application sans avoir à chercher dans les logs ou attendre qu'on te remonte des erreurs (avec toutes les imprécisions que ça implique).
Donc selon moi, il faut limiter le caractère défensif du programme (qui rend le code plus complexe et donc difficile à maintenir) et le laisser planter tranquille, quitte à gérer ce plantage. On peut faire ça grâce à des exceptions bien nommées et ultra spécifiques).
Pour moi , les exceptions sont également un moyen d'éviter la programmation défensive en blindant le code de conditions. Ainsi, mon code métier ne fait pas ou peu de vérification sur ce qu'il reçoit : c'est au code appelant d'envoyer les bonnes choses. Ça permet de garder un code clair et focalisé sur un rôle propre ; les conditions ayant tendance à proliférer. En revanche, si quelque chose se passe mal, je veux que mon code explose vite (Fail fast), pour prendre (ou non) des mesures.
Avec des exceptions dédiés (souvent je sous-classe juste StandardError) qui portent un nom sans ambiguité (GameAlreadyStarted, CharacterAlreadyDead, …) je sais tout de suite ce qui se passe (aussi bien sur le moment que quand je lis mes logs) et je peux catcher cette erreur seulement au plus au point si ça me chante (les fameux messages de type "L'application a rencontré une erreur, nos équipes ont été notifiées.") ou bien la prendre en charge plus proche de son appel pour tenter une remédiation.
Couplé à des outils de type error catcher (comme Airbrake (service) ou Errbit (self-hosted), qui ont un client pour PHP), ça permet de documenter et de monitorer ton application sans avoir à chercher dans les logs ou attendre qu'on te remonte des erreurs (avec toutes les imprécisions que ça implique).
Donc selon moi, il faut limiter le caractère défensif du programme (qui rend le code plus complexe et donc difficile à maintenir) et le laisser planter tranquille, quitte à gérer ce plantage. On peut faire ça grâce à des exceptions bien nommées et ultra spécifiques).