2009-11-26 5 views
24

J'ai créé la classe d'exception personnaliséeidentification Type d'exception dans un gestionnaire

public class Web2PDFException : Exception 
{ 
    public Web2PDFException(string message, 
     Exception innerException) 
     : base(message, innerException) 
    { 
    } 
} 

Dans ma demande, je veux savoir est exception throw est mon exception personnalisée ou non.

try 
{ 
} 
catch (Exception err) 
{ 
//Find exception type here 
} 

Répondre

33

MISE À JOUR: en supposant C# 6, les chances sont que votre cas peut être exprimé sous la forme d'un filtre d'exception. Telle est l'approche idéale du point de vue de la performance en supposant que votre exigence peut être exprimée en termes de celui-ci, par exemple:

try 
{ 
} 
catch (Web2PDFException ex) when (ex.Code == 52) 
{ 
} 

En supposant C# < 6, le plus efficace est d'attraper un type Exception spécifique et ne manipulation basé sur cela. Tout fourre-tout traitement peut être fait séparément

try 
{ 
} 
catch (Web2PDFException ex) 
{ 
} 

ou

try 
{ 
} 
catch (Web2PDFException ex) 
{ 
} 
catch (Exception ex) 
{ 
} 

ou (si vous avez besoin d'écrire un gestionnaire général - qui est généralement une mauvaise idée, mais si vous êtes sûr qu'il est préférable pour vous, vous êtes sûr):

if(err is Web2PDFException) 
{ 
} 

ou (dans certains cas, si vous avez besoin de faire des choses de la hiérarchie de type plus complexe qui ne peut pas être exprimé avec is)

if(err.GetType().IsAssignableFrom(typeof(Web2PDFException))) 
{ 
} 

ou de passer à VB.NET ou F # et utiliser is ou Type.IsAssignableFrom dans les filtres d'exception

+0

si (err est Web2PDFException) est que je avais besoin :) – Tomas

+0

Pour utiliser le " est "opérateur il n'a pas besoin de passer à VB.NET –

+0

@BeowulfOF: Je sais, mais s'il essaie juste de faire un filtrage basé sur les types - c'est-à-dire une sorte de capture conditionnelle etc., il peut être utile d'utiliser un * dans un filtre d'exception plutôt qu'un bloc de capture * - il peut s'agir d'une voie d'approche qui fonctionne. Ma suggestion initiale (et c'est toujours dans la réponse) est un est dans le bloc catch. La conclusion est que, étant donné que l'utilisation d'un «est» est normalement une mauvaise odeur, nous pourrions aussi bien avoir une liste de solutions possibles et laisser Tomas choisir ce qui lui convient le mieux dans son contexte spécifique. Mais oui, c'est peu probable. –

15
try 
{ 
    // Some code 
} 
catch (Web2PDFException ex) 
{ 
    // It's your special exception 
} 
catch (Exception ex) 
{ 
    // Any other exception here 
} 
+0

S'il y a 10 exceptions connues, la chaîne de capture aura l'air moche. – derek

1

Vous devez toujours prendre des exceptions aussi concrètes que possible, vous devez donc utiliser

try 
{ 
    //code 
} 
catch (Web2PDFException ex) 
{ 
    //Handle the exception here 
} 

Vous devriez bien sûr utiliser quelque chose comme ceci si vous insistez:

try 
{ 
} 
catch (Exception err) 
{ 
    if (err is Web2PDFException) 
    { 
     //Code 
    } 
} 
5
try 
{ 
} 
catch (Exception err) 
{ 
    if (err is Web2PDFException) 
     DoWhatever(); 
} 

mais il y a probablement une meilleure façon de faire ce que vous voulez.

+0

Pourquoi était-ce downvoted? C'est équivalent à plusieurs autres exemples. – jp2code

1

vous pouvez ajouter des informations supplémentaires à votre exception dans votre classe et puis quand vous attrapez l'exception que vous pouvez contrôler vos informations sur mesure pour identifier votre exception

this.Data["mykey"]="keyvalue"; //you can add any type of data if you want 

et vous pouvez obtenir votre valeur

string mystr = (string) err.Data["mykey"]; 

comme ça pour plus d'informations: http://msdn.microsoft.com/en-us/library/system.exception.data.aspx

+0

Je ne sais pas pourquoi cela a été abattu. Cela offre un moyen agréable de fournir des données supplémentaires à votre code. – jp2code

+0

@ jp2code Je devine parce qu'il ne répond pas à l'OP? –

54

Dans les situations où je don Je ne sais pas exactement quel type d'exception pourrait provenir d'une méthode, un petit truc que j'aime faire est de récupérer le nom de la classe de l'exception et de l'ajouter au journal des erreurs afin qu'il y ait plus d'informations.

try 
{ 
    <code> 

} catch (Exception caughtEx) 
{ 
    throw new Exception("Unknown Exception Thrown: " 
         + "\n Type: " + caughtEx.GetType().Name 
         + "\n Message: " + caughtEx.Message); 
} 

Je ne garantis pour traiter toujours des types d'exceptions individuellement, mais le supplément d'information peut être utile, surtout lorsqu'ils traitent avec le code de gens qui aiment capturer fourre-tout types génériques.

+6

Je suis confus ici (en particulier par les upvotes). Vous remplacez une exception utile par une pile avec une autre qui n'a que les hautes lumières? Même si vous avez fait l'exception, faites référence à 'caughtEx' en tant qu'enfant, je me demande quel est le point (si vous affichez le' exception.ToString() ', il vous montrera le type de toute façon). Je pourrais comprendre si vous étiez en train de l'enregistrer à ce stade avant de faire un 'jeter '... –

+4

Dans mon cas, j'avais besoin de cela pour la journalisation, donc' caughtEx.GetType(). Name' était exactement ce que je cherchais . Merci! – mayabelle

+0

@RubenBartelink Oui, En effet, le raisonnement est de faire apparaître l'exception dans un fichier journal au lieu de la trace de la pile un peu gênante. Comme avec n'importe quoi, cela dépend de ce dont vous avez besoin. En règle générale, je code la gestion des exceptions comme cela pendant le développement afin que je puisse facilement suivre les erreurs, puis les nettoyer ou les ajuster au besoin (en appelant les traces de la pile si nécessaire). Comme je l'ai dit, j'y ai surtout recours lorsque je travaillais avec des bases de code où la gestion des exceptions était négligée par les développeurs précédents. – Oskuro

1

Autre possibilité:

var exception = err as Web2PDFException; 

if (excecption != null) 
{ 
    Web2PDFException wex = exception; 
    .... 
} 
4

lieu de codage et recompilation dur, pourquoi ne pas simplement appeler la méthode GetType hors de l'exception réelle en utilisant le débogueur de Visual Studio?

Pour ce faire, lors du débogage on peut appeler des méthodes en utilisant le Immediate Window du débogueur. Par exemple, je devais savoir ce que l'exception et juste la propriété Name extrait de GetType en tant que telle, sans avoir à recompiler:

enter image description here