Gestion des exceptions dans les fonctions personnalisées

Question

Nous utilisons tous les blocs catch try. Mais quelle est la meilleure façon de gérer les erreurs dans les fonctions personnalisées?

Affichage d'un messagebox à l'utilisateur lorsque l'exception est levée (si possible au sein de la fonction), ou retourner une valeur indiquant qu'une erreur a été trouvée dans la fonction?

Answer 1

Cela dépend vraiment de la fonction, mais en général, je vous conseille contre l'avoir afficher une MessageBox à l'utilisateur; c'est une tâche pour l'interface utilisateur. Si la fonction (pour une raison valable) fait montrent une MessageBox, fournissent une surcharge qui est garanti d'être « silencieux », de sorte que l'appelant de la fonction peut empêcher la MessageBox. Mais, comme je l'ai dit, je pense qu'il est préférable de laisser l'appelant décider comment gérer l'exception. Après tout, il se peut que la fonction est appelée à partir d'un service Windows, où il n'y a pas l'interface utilisateur.

Je l'habitude d'utiliser une de ces approches:

• Pas attraper l'exception du tout, mais plutôt laisser la bulle vers le haut. Cela se fait simplement pas mettre en œuvre un bloc try-catch dans la fonction.
• Intercepter l'exception, faire quelque chose avec elle (comme l'exploitation forestière), et puis re-jeter.
• Intercepter l'exception, l'envelopper (comme InnerException) dans une nouvelle exception qui est levée, peut-être avec une certaine exploitation forestière fait.

Ceci est valable si la fonction elle-même ne peut pas gérer l'exception. Dans certains cas, il se peut que la fonction peut gérer l'état d'exception et d'effectuer encore ses travaux. Dans ces cas, bien sûr, pas d'exception sera levée par la fonction.

Answer 2

Je laisse toutes mes erreurs bouillonner au niveau supérieur, où j'utilise un gestionnaire d'erreur d'application pour les gérer tous.

Si j'ai une erreur spécifique que je sais peut se produire dans une fonction et cette fonction peut gérer, puis-je faire.

Temporisations, refs objet fixent pas etc monter au gestionnaire en haut.

Answer 3

Ne pas attraper une exception que vous ne pouvez pas faire quelque chose. Le code qui est jonché de blocs try / catch est difficile à lire, et signifie que votre code de gestion des exceptions ne figure pas dans un seul endroit pour faciliter l'entretien.

Si vous connectez simplement l'exception ou d'alerter l'utilisateur, cela doit être fait en haut de la pile (ou à vos limites de la couche d'application). Utilisez l'événement Application.ThreadException et l'événement AppDomain.CurrentDomain.UnhandledException et les raccorder aux gestionnaires d'événements dans votre Sub Méthode principale.