C# Renvoyer un élément de la poignée d'exception

Question

J'ai le code suivant dans une classe de la mienne. Le but de cette classe est d'obtenir le solde d'un serveur Web. Juste au cas où quelque chose ne va pas avec l'équilibre. Je vais gérer une exception. Cependant, tout cela est facile à faire. Mais je me demande ce que je retourne dans ma déclaration de capture.

La plupart des exemples que je regardais à juste écrire à la console en utilisant:

Console.WriteLine(ex.Message); 

Tout cela est très bien. Mais dans une application réelle, que font la plupart des développeurs?

//Download only when the webclient is not busy. 
     if (!wc.IsBusy) 
     { 
      // Sleep for 1/2 second to give the server time to update the balance. 
      System.Threading.Thread.Sleep(500); 

      try 
      { 
       // Download the current balance. 
       wc.DownloadStringAsync(new Uri(strURL)); 
      } 
      catch (WebException ex) 
      { 
       Console.Write("GetBalance(): " + ex.Message); 
      } 
     } 
     else 
     { 
      Console.Write("Busy please try again"); 
     } 

Ma fonction pour le moment renvoie la valeur vide. Et je me demande juste ce que je pourrais retourner si le client est occupé?

Un grand merci pour tous les conseils,

Answer 1

Ne pas attraper une exception si vous ne pouvez pas le manipuler. Si vous renvoyez juste une valeur, la méthode appelante doit vérifier si la valeur est un résultat réel ou juste un indicateur d'une exception. Et maintenant, cette méthode doit décider quoi faire et retourner. Et la méthode appelant cette méthode. Et la méthode ...

Alors laissez simplement l'exception monter en flèche dans la pile et l'attraper quelque part où vous pouvez la gérer. Peut-être directement sous l'interface utilisateur, puis afficher une boîte de message demandant si l'utilisateur veut réessayer ou afficher des informations sur la façon de résoudre le problème. Si vous n'avez pas d'interface utilisateur, attrapez-la quelque part où vous pouvez résoudre le problème et réessayez. S'il s'agit d'un problème temporaire, relancez l'ensemble de la tâche à un niveau raisonnable jusqu'à ce que l'appel aboutisse.

Si vous voulez enregistrer quelque chose, utilisez le modèle suivant pour consigner l'exception et la réimprimer.

try 
{ 
    DoStuff(); 
} 
catch (Exception exception) 
{ 
    Log(exception.ToString()); 

    throw; 
} 

Notez qu'il est throw; et non throw exception;. Si vous le faites plus tard, vous perdez la trace de la pile d'origine. Si vous pouvez déduire plus de détails sur la cause de l'exception, vous devez placer l'exception interceptée dans une exception plus significative avec des informations supplémentaires.

try 
{ 
    DoStuff(); 
} 
catch (SpecificMeaninglessException exception) 
{ 
    Log(exception.ToString()); 

    throw new MeaningfulException("Details about the error.", exception); 
} 
catch (Exception exception) 
{ 
    Log(exception.ToString()); 

    throw; 
} 

Answer 2

Vous pouvez ré-exécuter la méthode si le client est occupé mais attendez un certain temps avant que relances? Potentiellement avec un échec après x tentatives. Si à la place vous souhaitez passer à autre chose et simplement enregistrer le problème, votre instruction catch peut consigner l'exception dans un journal basé sur un fichier, un observateur d'événements, soumettre à une base de données, déclencher une alerte (email, SMS, etc.) il est nécessaire.

Answer 3

Vous devez utiliser la méthode

Exception.Message ex.ToString() contient une simple description de l'exception (par exemple "référence d'objet non définie ...").

Exception.ToString() contient une description de l'exception avec une trace de pile complète.

Exception Handling Best Practices in .NET

Answer 4

Dépend de la gravité de l'exception.

Je suggérerais à la recherche dans The Exception Block from Patterns & Practices

Answer 5

Si vous n'êtes intéressé que regarder l'exception que vous devez à nouveau jeter l'exception pour qui jamais projette de le manipuler sera toujours l'obtenir.

Answer 6

Vous ne voulez certainement pas masquer une exception non gérée. Laissez cette bulle remonter dans la pile. Mais si vous demandez ce qu'il faut retourner si le client Web est juste occupé, qu'en est-il de retournant un intervalle aléatoire ou un intervalle significatif que l'appelant de fonction devrait attendre avant de tenter de télécharger à nouveau la balance? Un nombre aléatoire pourrait répartir la charge ou atténuer un problème de collision. Un intervalle plus significatif pourrait être renvoyé en fonction de l'état actuel du serveur.