Choix de blocs de capture

Question

Je lis un article sur le C#. Il suggère que

A la fin du bloc de capture, vous avez trois choix :

- Relancer la même exception, en notifiant le code situé plus haut dans la pile d'appels de l'exception.
exception.

_**

- Lancer une exception différente, ce qui donne des informations plus riches sur les exceptions au code situé plus haut dans la hiérarchie. la pile d'appels.

- Laissez le fil tomber du bas du bloc de capture.

**_

Je ne parviens pas à comprendre ces points, il serait très utile que vous les clarifiiez en donnant un exemple simple.

Merci d'avance.

Mise à jour : Lorsque j'ai besoin de gérer une exception rejetée, dois-je avoir des blocs try .. catch imbriqués comme suit

try
{
   try
   {
   }
   catch(InvalidOperationException exp)
   {
     throw;
   }

}
 catch(Exception ex)
 {
    // handle the exception thrown by inner catch block
   // (in this case the "throw"   clause     inside the inner "catch")
 }
}

Answer 1

Eh bien, voici ces différentes options en code :

Option 1 : Rethrow

try
{
    // Something
}
catch (IOException e)
{
    // Do some logging first
    throw;
}

Option 2 : Lancer une autre exception

try
{
    // Something
}
catch (IOException e)
{
    // Do some logging first
    throw new SorryDaveICantDoThatException("Oops", e);
}

Option 3 : laisser le fil tomber du fond.

try
{
    // Something
}
catch (IOException e)
{
    // Possibly do some logging, and handle the problem.
    // No need to throw, I've handled it
}

EDIT : Pour répondre à la question supplémentaire, oui - si vous devez gérer une exception rejetée, cela doit être fait dans une portée externe, exactement comme indiqué dans la question. Mais c'est très rarement une bonne idée. En effet, catch Les blocs devraient être relativement rares en premier lieu, et les blocs imbriqués encore plus.

Answer 2

Voici les choix possibles. La différence entre 1 et 2 est que si une exception est levée et que vous voulez déboguer jusqu'à la position où elle a été levée, vous y arriverez avec l'option 1 (tout en bas dans le bloc try à l'objet spécifique). Avec l'option 2, vous n'arriverez qu'à cette ligne (throw new Exception2()).

3 c'est quand vous voulez ignorer l'exception et juste continuer

//1
catch (Exception ex)
{
    throw;
}

//2
catch (Exception ex)
{
    throw new Exception2();
}

//3
catch (Exception ex)
{
}
return something;

Answer 3

Dans la plupart des systèmes de production, la dernière chose que vous souhaitez est une exception non gérée. C'est pourquoi les instructions try et catch sont typiques.

Vous vous demandez peut-être pourquoi vous voudriez lancer une erreur que vous avez attrapée, et voici quelques exemples concrets.

1. Vous avez attrapé une exception dans une application WCF, enregistré l'exception, puis lancé une faultException à la place pour être retourné au client WCF. De la même manière, vous pourriez avoir un asmx traditionnel, attraper une exception, puis lancer une exception SOAP vers le client. Le point est que certaines exceptions doivent respecter certaines règles : une exception standard .net ne serait pas bien digérée par un client WCF par exemple.

2. Vous avez attrapé une exception quelque part dans votre code, vous avez enregistré l'exception et peut-être même pris des mesures. Mais plus haut dans votre code, vous avez une autre routine qui attend également des exceptions, à ce point plus haut, une exception pourrait facilement changer le flux de travail. En attrapant l'exception en bas de l'échelle, le code en haut de l'échelle n'est pas au courant de l'exception, donc vous devez renvoyer l'exception pour qu'elle soit attrapée en haut de l'échelle, afin que le code que vous avez écrit en haut puisse ajuster le flux de travail. Bien sûr, rien de tout cela n'arrive par magie, tout doit être codé, et différents programmeurs utilisent différentes techniques.

3. Vous pourriez également vouloir attraper une exception autour d'une ou de quelques déclarations, par exemple obtenir une valeur de configuration à partir d'un fichier XML, si quelque chose ne va pas, .net pourrait simplement retourner une référence d'objet non définie. Vous pouvez attraper cela, puis relancer l'exception comme "Configuration Value : Customer Name not provided".

J'espère que cela vous aidera.

Answer 4

1) Rejeter

try
{
    ...
}
catch (Exception e)
{
    ...
    throw;
}

2) Lancer une nouvelle exception

try
{
    ...
}
catch (Exception e)
{
    ...
    throw new NewException("new exception", e);
}

3) tomber

try
{
    ...
}
catch (Exception e)
{
    ...
}

Answer 5

Relance la même exception :

try
{
    // do something that raises an exception
}
catch (SomeException ex)
{
    // do something with ex
    throw;
}

lancer une exception différente

try
{
    // do something that raises an exception
}
catch (SomeException ex)
{
    // do something with ex
    throw new SomeOtherException(ex);  // NOTE: please keep ex as an inner exception
}

laisser le fil tomber :

try
{
    // do something that raises an exception
}
catch (SomeException ex)
{
    // do something with ex
}
// the code will finish handling the exception and continue on here