un essai principal catch dans les méthodes d'appel de méthode qui n'implémentent pas un try-catch

J'ai une méthode doSomething() qui a un try catch block, dans lequel j'appelle une autre méthode.un essai principal catch dans les méthodes d'appel de méthode qui n'implémentent pas un try-catch

public void doSomething() 
    { 
     try 
     { 
      doSomethingElse(); 
     } 
     catch 
     { 
      // catch implementation goes here 
     } 

    }

Dans cette autre méthode doSomethingElse() Je n'ai pas bloc catch try. Je suis dépendant du try-catch de la méthode principale pour gérer l'exception. S'il y a des exceptions dans doSomethingElse(), ils seront passés au niveau du bloc try-catch de la méthode doSomething.

Y at-il un problème avec cette approche?

Merci pour votre temps.

Source

2010-10-12 user20358

Non, rien de mal à cela. –

Une recommandation: Si votre méthode doSomething() existe uniquement dans le but d'exécuter la méthode doSomethingElse() dans un try/catch, je rends privée la méthode doSomethingElse() afin que les appelants d'API puissent seulement appeler la méthode qui attrape le des exceptions). – Chris

Une grosse chose fausse est d'avaler complètement les exceptions qui sont lancées. Assurez-vous de les gérer en conséquence, éventuellement en attrapant les affaires en premier (si quelque chose est lancé par 'doSomethingElse'), et éventuellement en gérant les autres si nécessaire. –

Ceci est tout à fait légitime.

Laisser les exceptions surgir là où vous le pouvez/savoir quoi en faire.

Il est recommandé de ne pas encombrer votre code avec des blocs try/catch qui n'ajoutent rien.

Cependant, avoir des blocs de saisie vides est mauvaise pratique (bien que je suppose que le code que vous avez posté est une version simplifiée omettant le code de bloc catch).

Source

2010-10-12 12:09:28 Oded

oui J'ai omis le bloc catch pour plus de simplicité. Merci. – user20358

C'est ok, mais vous oubliez ; après doSomethingElse()

Source

2010-10-12 12:09:13 Svisstack

SO n'a pas de compilateur donc je ne pensais pas que ça m'intéresserait ici :) – user20358

Rien à redire.

Comme d'autres l'ont dit, ne pas avaler des exceptions. Il peut également être une bonne idée de ne pas lancer une nouvelle exception; plutôt, juste catch (Exception) et throw il. Bien sûr, il devrait également être noté pour essayer et être spécifique avec des exceptions, et pas simplement utiliser le Exception par défaut.

Source

2010-10-12 12:18:46 Harry

Merci.Dans doSomethingElse(); Je n'utilise pas non plus l'instruction throw. Comme il est appelé dans le doSomething(); méthode, je m'attends à ce qu'il soit attrapé dans le bloc try-catch de la méthode doSomething(). – user20358

Ouais c'est bien parce que vous n'avez pas d'essayer/attraper dans doSomethingElse. Les exceptions sont avalées quand vous voulez propager une erreur d'un essai/rattraper un essai/attraper dans une méthode plus basse dans la pile mais vous ne la lancez pas du tout. Ensuite, les problèmes se produisent;) – Harry

C'est mauvais. Pour attraper une exception, vous devez restaurer l'état du programme, comme si doSomethingElse() n'était jamais appelé. Cela dépend beaucoup de ce que fait la méthode, mais il est généralement assez inhabituel d'écrire une méthode sans aucun effet secondaire. S'il en a, ces effets secondaires doivent être annulés. Seul doSomethingElse() peut le faire, la méthode doSomething() est impuissante à deviner combien de ces effets secondaires ont réellement été exécutés. Et ne peut donc pas restaurer l'état de manière fiable.

Ceci est particulièrement le cas lorsque vous saisissez toutes les exceptions. Vous attraperez aussi les méchants. Comme AccessViolation ou FatalExecutionEngineError, les exceptions qui laissent le CLR lui-même dans un état inconnu, vous ne pouvez jamais le restaurer. Ce qui se passe ensuite est assez imprévisible. Vous obtiendrez une foule d'exceptions supplémentaires seulement si vous êtes chanceux. Les diagnostiquer est impossible, vous avez jeté des informations précieuses.

Source

2010-10-12 13:25:57

un essai principal catch dans les méthodes d'appel de méthode qui n'implémentent pas un try-catch

Répondre

Questions connexes