Automaticamente vedere quali funzioni possono restituire eccezione in c#

StackOverflow https://stackoverflow.com/questions/915941

  •  06-09-2019
  •  | 
  •  

Domanda

niente di più frustrante che vedere il tuo codice crash nel debugger su un metodo che exceptionned e non try/catch.

C'è un modo semplice per eseguire la scansione attraverso le sorgenti e i tag di tutte le funzioni che potenzialmente possono generare eccezioni?

La build in visual assist avere qualche opzione nascosta per la colorazione di queste funzioni in un colore specifico?

grazie

R

È stato utile?

Soluzione

Credo Redgate hanno qualche strumento per questo "Eccezione Hunter" Fanno pagare per esso dopo una prova.

http://www.red-gate.com/products/Exception_Hunter /index.htm

Altri suggerimenti

Tutto il codice, ma il più banale potrebbero generare eccezioni (su memoria, per lo meno). Sei probabilmente meglio a scrivere il codice in difesa, con almeno un try / catch globale, piuttosto che cercare di microgestire cui sezioni di codice sarà o non generare eccezioni.

No, non c'è modo di fare automaticamente questo né v'è un buon modo per ottenere un elenco di tutte le possibili eccezioni generate da un metodo. Qui ci sono alcuni motivi per cui

  1. Si consideri implicitamente gettati eccezioni come StackOverflowException può essere gettato in qualsiasi momento e da qualsiasi metodo. Si deve supporre che ogni metodo nel CLR può gettare questi tipi di eccezioni
  2. Riflesso e / o delegati possono nascondere il codice vero e chiamati in un particolare metodo quindi non è possibile esaminare tutti i possibili percorsi di codice di un metodo.
  3. Questo richiederebbe l'ispezione IL vs. metadati.
  4. In Net non v'è alcun obbligo di documentare eccezioni esplicitamente gettati da un API

Come altri hanno detto, non so se si trova un modo infallibile per farlo in C# in quanto non supporta controllato eccezioni.

Come un po ' di parte, questo mi ha ricordato in un'intervista con Anders Hejlsberg discutere "Il problema con Eccezioni selezionate".Non sto cercando di fiamma controllato eccezioni, ma suggerendo che si leggono Ander la logica che sta dietro a C#'s eccezione design e il modo suggerito per la gestione delle eccezioni:centralizzato di gestione delle eccezioni.

Credo che la ReSharper ti dà suggerimenti su eccezioni. Ma a causa della ragione che C # non supporta eccezioni controllate, non v'è modo per determinare le eccezioni. Forse strumenti di analisi del codice come NDepend supportano questa.

Tutto può generare un'eccezione. Controllare MSDN per un elenco di eccezioni che può essere gettato da un metodo.

Tutti i metodi non-vuote possono generare eccezioni in una forma o nell'altra. Se siete preoccupati per le eccezioni che hai personalmente generato, è possibile visualizzare dal intellisense nello stesso modo i metodi quadro fanno tramite documentazione XML, in questo modo: 

/// <summary>  
/// I seem to have written a method to do a thing.
/// </summary>  
/// <exception cref="System.Exception">An unfortunate failure.</exception>
public void DoSomething()
{
   /* ... */
}

Ogni codice può potenzialmente causare un'eccezione è il vostro lavoro per cercare di anticipare i questo!

Ci sono una serie di strumenti di terze parti che possono aiutare a trovare alcuni errori comuni per esempio FxCop e strumenti come il refactoring possono fare proposte.

C'è un po 'di lavoro stato fatto nel momento in cui si può aiutare con ricerca di potenziali eccezioni. Date un'occhiata in PEX, che può contribuire a generare test per le funzioni: research.microsoft.com/en-us/projects/Pex/ (link sembra essere giù al momento del distacco)

Un altro settore interessante è contratti di codice (in arrivo .net 4 / disponibili come spec #). contratti di codice permettono di scrivere affermazioni che specificano le condizioni che devono essere soddisfatte. Questi possono essere prima e dopo la funzione in fase di chiamata e si può anche dichiarare invarianti. Una condizione potrebbe essere qualcosa di semplice come valore! = Null. Queste condizioni sono poi analizzate in fase di compilazione e di runtime per controllare alcun codice percorsi li violano.

Mentre gli altri hanno detto, si dovrebbe presumere che ogni singola riga di codice può generare un'eccezione, a meno che non hai dimostrato che non si può. La domanda migliore è, "che cosa avete intenzione di fare al riguardo?"

In generale, non si dovrebbe essere pescatore di eventuali eccezioni a tutti.

Naturalmente, tutto il resto è un'eccezione a questa regola. Ha senso per intercettare un'eccezione per effettuare il login (se l'ambiente non lo fa per voi, come fa ASP.NET). Ha senso per intercettare un'eccezione al fine di sostituirlo con un altro eccezione che fornisce maggiori dettagli sul contesto: 

public int GetConfiguredInteger(string name) {
    string s = null;
    try {
        s = GetStringFromConfigFile(name);
    }
    catch (IOException ex) {
        throw new Exception(String.Format(
            "Error in configuration file foo.config when processing {0}", name),
            ex);
    }
    return int.Parse(s);
}

Il chiamante non poteva sapere che l'IOException è stato causato da un file di configurazione se non li avessi detto. Si noti inoltre come ho ignorato tutte le eccezioni non legati al file di I / O. In particolare, si noti che l'int.Parse non è nemmeno all'interno del blocco try / catch.

Ci sono un piccolo numero di altri tali eccezioni, ma l'idea di base di eccezioni cattura è:. Non farlo a meno che non sarebbe stato peggio se non l'avete fatto

C'è un riflettore aggiungere in Eccezione Finder che mostrerà quali eccezioni potrebbero essere gettato con un metodo. Non ho usato, ma ha visto un esempio di esso in una riunione del gruppo di Net utenti.

C'è uno strumento là fuori che può fare questo. Si potrebbe scaricare la trial e vedere se ti piace. Io non credo che sarebbe stato così necessario, ma se si sta lavorando per una società e faranno pagare per questo si potrebbe desiderare di esaminare il problema. Come è stato detto prima che ci sono troppe possibili eccezioni che essere sollevate. Scopri Excpetion Hunter

Eccezione Hunter citato da poche persone è un buon strumento per aiutare con questo. Non so se ha un tie-in con il commento <exception> XML-Doc in modo da poter far rispettare la documentazione di eccezioni generate dal codice.

Trovo molto più frustrante per rompere all'interno di un blocco catch esterno e scavare la mia strada fino al punto effettivo in cui l'eccezione happend.

La maggior parte del tempo se un'eccezione è stato gettato e non mi aspettavo che ho trovato un bug ed è più facile da risolvere, se non è stato offuscato da qualche gestione delle eccezioni FARE-nulla.

Modifica Dal momento che i tuoi esempi è in realtà una buona io non sono ancora convinto che un tale strumento potrebbe aiutare. Ci sarebbero tante possibili eccezioni che letteralmente ogni riga di codice potrebbe gettare che si avrebbe un tempo difficile trovare le "interessanti" quelli.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top