C # Manipulation d'exception, quelle clause de capture à utiliser?

Quelle exception à utiliser dépend vraiment du code dans le bloc d'essai. En général, vous souhaitez attraper des exceptions avec lesquelles vous pouvez faire quelque chose avec et laisser des exceptions que vous n'avez pas de pouvoir surviennent à des niveaux élevés de votre code où vous pouvez effectuer certaines mesures qui font depuis. L'une des erreurs les plus courantes que je vois que les gens font de tenter d'attraper des erreurs qu'elles n'ont aucune capacité à gérer.

Par exemple P>

Void ChoseFile()
{
     try
     { 
         string FileName = GetInputFile()
     }    
     catch( InvalidFileSelectedException ex)
     { 
         //In this case we have some application specific exception 
         //There may be a business logic failure we have some ability 
         //to infomr the user or do an action that makes sense  
     }
     catch(FileNotFoundException exfilenot found)
     { 
         //In this case we can do somthing different the the above 
     }
     catch(Exception ) 
     { 
         //Normal I would not use this case we have an error we don't know what to do 
         //with. We may not have a usefull action.  At best we can log this exception                               
         // and rethrow it to a higher level of the application that can inform the user
         // fail the attempted action.  Catching here would only suppress the failure.
      }

} 

Philosophie de manutention d'exception Je suis sûr que vous pouvez trouver de nombreuses autres philosophies

code de manière défensive. Attraper des exceptions est plus chère que d'empêcher l'erreur en premier lieu.

Ne pas attraper une exception et l'enterrer en ne manipulant pas. Vous pouvez passer de nombreuses heures à essayer de trouver une erreur qui a été supprimée.

Les erreurs de journal que vous attrapez. Cela aide à analyser le problème. Vous pouvez vérifier si plus d'un utilisateur a le même problème Je préfère une base de données pour la journalisation, mais un fichier plat ou le journal des événements conviennent également. La solution de base de données est la plus facile à analyser, mais peut introduire des erreurs supplémentaires.

Si l'erreur est due à des données incorrectes saisies par l'utilisateur, informez-en l'utilisateur du problème et laissez-les réessayer. Permettez toujours une voie d'évacuation s'ils ne peuvent pas résoudre le problème.

attraper l'erreur aussi proche de la source que possible Cela pourrait être une procédure de base de données, une méthode dans une couche d'accès aux données (DAL) ou un autre emplacement.

Gestion de l'exception est différent de la capturer. Vous devrez peut-être repenser l'exception afin qu'elle puisse être traitée plus haut de la pile ou dans l'interface utilisateur.

Retirhing L'exception peut être faite d'au moins deux manières. À jeter seul ne modifie pas la pile. Dresser EX modifier ou ajouter à la pile sans avantage.

Parfois, il est préférable de ne pas attraper une exception, mais laissez-la plutôt la bulle.

Si vous écrivez des services (Web ou Windows) qui n'ont pas d'interface utilisateur (UI), vous devez toujours enregistrer l'erreur. Encore une fois, cela est donc que quelqu'un puisse analyser le journal ou le fichier de base de données pour déterminer ce qui se passe.

Vous voulez toujours que quelqu'un sache qu'une erreur s'est produite.

Avoir beaucoup de déclarations de capture pour un bloc d'essai peut rendre votre code plus difficile à maintenir, surtout si la logique de vos blocs de capture est complexe. Au lieu de cela, code de manière défensive.

N'oubliez pas que vous pouvez avoir essayé de prendre des blocs de capture dans des blocs de capture.

Aussi, n'oubliez pas d'utiliser le bloc enfin le cas échéant. Par exemple, la fermeture des connexions de base de données ou des poignées de fichier, etc.

hth Harv