2009-07-10 10 views
3

Laquelle des manières suivantes de traiter cette condition préalable est plus souhaitable et quelles sont les plus grandes implications?Meilleure façon de gérer une exception de précondition type?

1:

If Not Exists(File) Then 
    ThrowException 
    Exit 
End If 
File.Open 
...work on file... 

2:

If Exists(File) Then 
    File.Open 
    ....work on file... 
Else 
    ThrowException 
    Exit 
End 

Note: La vérification de l'existence de fichiers est juste un exemple d'une condition préalable à la poignée. Clairement, il y a un bon cas pour laisser les vérifications d'existence de dossier jeter leurs propres exceptions vers le haut.

+3

Que diriez-vous du numéro 3: Laisser File.Open jeter l'exception? – balpha

+0

bien dit, s'il vous plaît ajouter cette troisième option – dfa

+0

(btw., Lire que "* What * about ..."), je ne laisse pas entendre que ce serait nécessairement la meilleure option, mais je pense que c'est un choix valide) – balpha

Répondre

1

C'est un truc de style. Les deux fonctionnent bien mais je préfère l'option 1. J'aime quitter ma méthode dès que je peux et avoir tous les contrôles à l'avant.

4

Je préfère la première variante de sorte qu'il meilleurs documents qu'il ya des conditions préalables

1

Lisibilité de première approche est supérieure à la seconde.
La deuxième option peut s'emboîter assez rapidement si vous avez plusieurs conditions préalables à vérifier; de plus, cela suggère que le if/else est en quelque sorte dans le flux normal, alors que ce n'est vraiment que pour des situations exceptionnelles.

De même, l'expressivité de la première approche est donc supérieure à la seconde. Comme nous parlons de préconditions, elles devraient être vérifiées au début de la procédure, juste pour s'assurer que le contrat est respecté; Pour cette raison, la vérification complète devrait être séparée de la partie restante de la procédure.

Pour ces deux raisons, j'irais certainement pour la première option.


Remarque: Je parle ici de conditions préalables: Je pense que le contrat de votre fonction définit explicitement le fichier comme existant, et donc de ne pas avoir ce serait un signe d'erreur de programmation.
Sinon, si nous parlons simplement de la gestion des exceptions, je laisserais simplement cela à File.Open, en gérant cette exception seulement s'il y a une idée sur la façon de procéder.

1

Toutes les exceptions doivent être produites au niveau approprié. Dans ce cas, votre exception est un problème open(), qui est géré par l'appel open(). Par conséquent, vous ne devez pas ajouter de code d'exception à votre routine, car vous dupliqueriez des éléments. Ceci est valable à moins que:

  1. vous voulez faire abstraction de votre backend IO (disons que votre routine de haut niveau peut utiliser le fichier ouvert, mais aussi MySQL dans le futur).Dans ce cas, il serait préférable que les codes client connaissent une exception plus standard et qu'une exception unique soit produite si des problèmes IO surviennent
  2. la présence d'une exception de niveau inférieur implique une exception de niveau supérieur avec une sémantique de haut niveau (par exemple, non être capable d'ouvrir un fichier de mot de passe signifie qu'aucune autorisation n'est possible et donc vous devriez lever quelque chose comme UnableToAuthenticateException)

En ce qui concerne le style de codage de vos deux cas, j'irais certainement pour le premier. Je déteste les longs blocs de code, notamment sous ifs. Ils ont également tendance à nicher et si vous choisissez la deuxième stratégie, vous finirez par indenter trop.

2

La séparation du contrôle de pré-condition du travail n'est valide que si rien ne peut changer entre les deux. Dans ce cas, un événement externe peut supprimer le fichier avant de l'ouvrir. Par conséquent, la vérification de l'existence d'un fichier a peu de valeur, l'appel ouvert doit vérifier de toute façon, laisser produire l'exception.

1

Une véritable condition est quelque chose qui, si elle se produit, est un bug dans la situation appelant: vous concevez une fonction dans certaines conditions, mais ils sont tiennent pas, l'appelant doit jamais appelé la fonction avec ces Les données.

Votre cas de ne pas trouver un fichier pourrait être comme ceci, si le fichier est requis et son existence est vérifiée avant dans une autre partie du code; cependant, ce n'est pas tout à fait le cas, car djna dit: la suppression du fichier ou la défaillance du réseau pourrait provoquer une erreur juste quand vous ouvrez le fichier.

Le traitement le plus commun est alors d'essayer d'ouvrir le fichier, et de lever une exception en cas d'échec. Ensuite, en supposant qu'une exception n'a pas été levée, continuez avec le travail normal.

Questions connexes