C# che tipo di eccezione dovrei aumentare?

Question

Sono attualmente in un tentativo di cattura trovare se una proprietà è stata impostata correttamente per il valore booleano che dovrebbe essere simile a questo ...

public void RunBusinessRule(MyCustomType customType) 
{ 
    try 
    { 
     if (customType.CustomBoolProperty == true) 
     { 
      DoSomething(); 
     } 
     else 
     { 
      throw new Exception("This is obviously false or possibly null lets throw up an error."); 
     } 
    } 
    catch(Exception) 
    { 
     throw; 
    } 
} 

Ora l'accordo con gettando questo errore per me è che io sono utilizzando l'analisi di origine di Microsoft e mi viene visualizzato un messaggio di errore "CA2201: Microsoft.Usage: Object.RunBusinessRule (MyCustomType) crea un'eccezione di tipo 'Exception', un tipo di eccezione che non è sufficientemente specifico e non dovrebbe mai essere generato dal codice utente. Se questa eccezione può essere lanciata, utilizzare un diverso tipo di eccezione

Soooo Quale eccezione dovrei buttare che sarebbe abbastanza specifica per Microsoft .., per la circostanza di lanciare un errore sulla gestione della logica della mia applicazione e quando voglio "lanciare".

Answer 1

ArgumentException 
InvalidOperationException 
FormatException 

L'argomento superato non era buono.

Answer 2

ArgumentException forse?

Un caso potrebbe essere fatto per InvalidOperationException, anche.

Answer 3

Dovresti lanciare un'eccezione?

Avere un falso valore booleano non è esattamente una circostanza eccezionale.

EDIT

La mia risposta originale era un po 'laconico quindi mi elaborare ...

Dal tuo esempio, non è chiaro cosa gli oggetti reali, proprietà e metodi rappresentano. Senza queste informazioni, è difficile stabilire quale tipo di eccezione, se presente, è appropriata.

ad esempio, mi piacerebbe prendere in considerazione quanto segue un uso perfettamente valido di un'eccezione (e il codice vero e proprio potrebbe ben essere simile a questo, ma non possiamo dire dal vostro esempio):

public void UpdateMyCustomType(MyCustomType customType) 
{ 
    if (!customType.IsUpdateable) 
     throw new InvalidOperationException("Object is not updateable."); 

    // customType is updateable, so let's update it 
} 

Ma nel caso generale, senza sapere di più sul tuo modello di dominio, direi che qualcosa di simile (un falso valore booleano) non è davvero eccezionale.

Answer 4

Un leggero a parte, ma si potrebbe semplificare il codice in qualche modo ...

public void RunBusinessRule(MyCustomType customType) 
{ 
    if (customType.CustomBoolProperty == false) 
    { 
     throw new Exception("This is obviously false or possibly null lets throw up an error."); 
    } 

    DoSomething(); 
} 

Per quanto riguarda il tipo di eccezione per gettare, si potrebbe considerare ApplicationException o InvalidOperationException, oppure si potrebbe definire il proprio tipo di eccezione.

Answer 5

Creare la propria eccezione che estende Exception. Es .: RuleViolationException

Answer 6

Crea la tua eccezione personalizzata estendendo System.Exception e gettala. Puoi diventare ancora più pazzo e avere un intero albero di tipi di eccezioni, se vuoi.

Answer 7

Si potrebbe semplicemente creare un ValidationException personalizzato che viene utilizzato solo per la convalida della logica aziendale. Oppure potresti creare un'eccezione di convalida separata per ogni tipo di errore di convalida, anche se probabilmente è un sovraccarico.

Answer 8

So che una domanda è di circa un'eccezione ma penso che sarebbe più opportuno fare un assertation qui:

// Precondition: customType.CustomBoolProperty == true 
System.Diagnostics.Debug.Assert(customType.CustomBoolProperty) 
DoSomething(); 

Answer 9

eccezione InvalidArgument va bene, ma meglio ancora, un ApplicationException.

Answer 10

La risposta qui è che non si devono fare eccezioni. Perché lanciare un'eccezione solo per riprenderla in un secondo e ripensarla?

Answer 11

Non proprio quello che stavi chiedendo, ma ci sono molte persone che hanno già fornito risposte che sono d'accordo, ma dovresti anche evitare di usare solo la cattura (Eccezione ex).

È una pratica molto migliore cercare di intercettare le eccezioni specifiche che sono possibili prima e, se necessario, catturare l'Expector generico. ad esempio:

try{ 
    MyMethod(obj); 
}catch (NullReferenceException ne){ 
    //do something 
} 
catch(UnauthorizedAccessException uae){ 
    //do something else 
} 
catch(System.IO.IOException ioe){ 
    //do something else 
} 
catch(Exception){ 
    //do something else 
} 

Answer 12

Le altre risposte vanno bene per una risoluzione rapida, ma idealmente se si sa al momento della compilazione che un certo metodo non dovrebbe mai essere invocato utilizzando alcuni parametri, è possibile impedire che da sempre accade ereditando il vostro tipo personalizzato , installandolo solo quando quel bool personalizzato è vero, e ora il tuo metodo sembra.

public void RunBusinessRule(MyInheritedType inheritedObject) 
{ 
    //No need for checks, this is always the right type. 
    //As a matter of fact, RunBusinessRule might even belong to MyInheritedType. 
} 

Questa è la I in SOLID.

Answer 13

Penso che dovresti evitare le eccezioni per la logica del codice.

suggerisco di modificare il metodo per restituire il risultato del metodo come un tipo bool allora si può decidere il modo appropriato per mostrare un messaggio di errore per l'utente al momento della chiamata al metodo:

public bool RunBusinessRule(MyCustomType customType) 
{ 
    try 
    { 
     if (customType.CustomBoolProperty == true) 
     { 
      DoSomething(); 
      return true; 
     } 

     return false; 
    } 
    catch(Exception) 
    { 
     throw; 
    } 
}