PHP : Les exceptions

[Xenos]

Quand tu peux pas classer les choses en arbre, les interfaces passent bien. Donc pour les niveaux d'erreurs, des classes et des héritages pas de soucis (ca se classe bien en cascade), mais quand tu ajoutes la nature de l'erreur, une erreur d'accès fichier par exemple, cela devient moins simple... Ca peut très bien être une erreur irrattrapable (impossible d'accéder à un fichier PHP requis ou au fichier de template par exemple), tout comme cela peut être une erreur "normale" (accès à un fichier de stats d'un nouveau joueur, le fichier n'existe pas, l'exception est solvable sans soucis car il suffit de créer ce fichier).

D'ailleurs, ce serait plutôt le "niveau" de l'erreur que je mettrai en interface, plutôt que son "type" (FileAccessException?)

[atra27]

Ca syit le principe solid de la ségrégation par interface.
Autrement dit chaque classe doit proposer proposer une interface. Cela permet de separer l'implémentation de l'utilisation.
Après comme tous les principes, y a trop peu, et trop trop. A chacun sa méthode.
Je trouve que les interface de Xenos sont une bonne idée si on a besoin d'un tel niveau de granularité sur une grosse application. Ca peux permettre d'afficher un message d'erreur générique par exemple, ou de filtrer les exceptions par type au moment du catch (on viole le principe de liskov ici hein)

Le but d'une exception c'est quand meme de:
- Logguer les erreurs pour permettre leur correction
- Avertir l'utilisateur que quelque chose fonctionne pas.
- Permettre a l'application de rester dans un état consistant

Essayes de voir si tu as vraiment beaucoup d'erreurs differentes a gérer ou pas?

[Xenos]

Le but d'une exception c'est quand meme de:
- Logguer les erreurs pour permettre leur correction
- Avertir l'utilisateur que quelque chose fonctionne pas.

Pas dit, car l'exception peut être "voulue" (lever une exception si le fichier de stats du joueur n'existe pas, catcher l'exception, créer le fichier, et donc rattraper le coup). Dans ce cas, log & avertissement ne sont pas nécessaires.

[Max72]

Oui il y a pas mal d'erreurs à gérer, forcément, avec des contraintes différentes.
Par exemple pour un système de cache, si le dossier spécifié n'est pas 'writable', ça lève une erreur mais rien n'empêche de continuer le script.
Par contre si un fichier n'est pas trouvé, inutile de continuer le script.

[atra27]

Pas dit, car l'exception peut être "voulue" (lever une exception si le fichier de stats du joueur n'existe pas, catcher l'exception, créer le fichier, et donc rattraper le coup). Dans ce cas, log & avertissement ne sont pas nécessaires.

D'ou le "Permettre a l'application de rester dans un état consistant", même si ça implique par exemple de catcher l'exception et de mettre en place une action palliative (même si cette action se résume a ne rien faire, c'est un choix pris par le dev, pas un bug caché).

Un petit ajout au passage, il existe des services comme rollbar ( http://rollbar.com/ ) qui permettent de loguer les exception non catchées.
Je l'utilise sur mon portfolio et sur quelque autres projets.
Au passage, si le coté webservice tiers ne te plais pas, il existe errbit ( https://github.com/errbit/errbit ).