Utilisation d'un code pour une exception. Utile?

Question

Je ne sais pas si des exceptions fonctionnent de la même façon dans chaque langue, mais je suis en utilisant PHP et je me demandais quand je fais quelque chose comme ceci:

if (!$this->connection[0]->query($this->query)) 
throw new QueryFailedException($this->connection[0]->error); 

Est-il nécessaire de fournir un code le deuxième paramètre? Par exemple:

if (!$this->connection[0]->query($this->query)) 
throw new QueryFailedException($this->connection[0]->error,123); 

Maintenant le code est 123 ... Je ne peux pas penser à un besoin pour cela. Est-ce qu'il y a un? Dans ce cas le message contient la requête, le nom d'exception est QueryFailedException qui explique le type d'exception, l'exception elle-même contient le fichier, la ligne et la trace de pile, donc, je ne peux pas penser à quoi que ce soit.

Answer 1

Le code d'erreur était une fonctionnalité utilisée lorsqu'il n'y avait pas de langage orienté objet. La seule chose qui pourrait vous aider à comprendre ce qui s'est mal passé était le code d'erreur. Dans un langage orienté objet, l'objet EST votre code d'erreur. À moins que, dans des cas spécifiques, plus d'une chose puisse lancer exactement la même erreur ET qu'elles soient traitées de différentes manières, déposez-la. En outre, vous fournirez une meilleure explication à ceux qui déboguent votre code si vous avez laissé un message au lieu d'un code d'erreur insignifiant, donc si vous pensez que l'exception a besoin de plus d'informations, remplissez le champ Message d'erreur.

Answer 2

Le code d'erreur est un champ pouvant être utilisé pour fournir des informations plus détaillées. Si par exemple vous avez deux choses qui peuvent générer la même exception, le code pourrait être utilisé pour donner plus de détails.

Answer 3

Si vous avez une "source d'erreur" qui fonctionne sur les codes d'erreur et que vous la "faites la promotion" aux exceptions, vous pouvez inclure le code d'erreur réel dans l'exception. a) il ne fait aucun mal et b) peut-être que vous ne voulez pas avoir une classe d'exception pour chaque code d'erreur qui peut se produire ou non (et pratiquement personne ne se soucie d'un système en cours d'exécution). Nous prendrons le MySQL server errors comme exemple. Vous pourriez créer une classe pour chacun de ces codes

class MySQLException_ER_HASHCHK extends MySQLException 
class MySQLException_ER_NISAMCHK extends MySQLException 
class MySQLException_ER_NO extends MySQLException 
class MySQLException_ER_YES extends MySQLException 
class MySQLException_ER_CANT_CREATE_FILE extends MySQLException 
class MySQLException_ER_CANT_CREATE_TABLE extends MySQLException 
class MySQLException_ER_CANT_CREATE_DB extends MySQLException 
class MySQLException_ER_DB_CREATE_EXISTS extends MySQLException 
class MySQLException_ER_DB_DROP_EXISTS extends MySQLException 
.... 

mais en réalité ... qui s'en soucie? Qui va vraiment les attraper individuellement? Dans presque tous les cas, il n'y aura qu'un catch (MySQLException $ mex) dans le code de l'application et peut-être, juste peut-être qu'il cherche un code spécifique où il fait peu ou pas de différence pour le codeur s'il y a deux catch-blocks ou un bloc if/switch. Maintenant vous avez beaucoup de classes "mortes" et personne - excepté l'analyseur - ne se soucie d'eux. (d'un autre côté, "tout ce qui vaut la peine d'être fait en vaut la peine")
Et même si vous fournissez une certaine granularité, je pense que cela n'a pas de sens d'aller au-delà. ayant une classe d'exception pour chaque SQLState (? est-ce que du sens SqlState ne sais pas, juste un exemple)

class MySQLException_HY000 extends MySQLException 
class MySQLException_HY001 extends MySQLException 
class MySQLException_XA100 extends MySQLException 
class MySQLException_XA102 extends MySQLException 

Et puis vous voudrez probablement inclure le code d'erreur - pourquoi perdre cette information même si/même si votre code habituellement ne l'évalue pas?

Answer 4

Si vous le pouvez, il est très bon de définir un code d'exception. Si vous ne changez pas votre code pour lancer des exceptions différentes en fonction des données que vous obtenez de votre base de données. Le code d'erreur, dans OOP, est le nom de classe d'exception lui-même, de sorte que vous pouvez interpréter chacun d'entre eux dans un seul try mais avec plusieurs clauses catch.

try { 
    // code here 
} catch (AccessDeniedException $e) { 
// do something 
} catch (Exception $e) { 
    // do something else 
}