Qual è la differenza tra:Utilizzando cattura senza argomenti
catch
{
MessageBox.Show("Error.");
}
e:
catch (Exception ex)
{
MessageBox.Show("Error.");
//we never use ex, so is it better to use catch without arguments?
}
Come da .NET 2, se non si modifica la configurazione? Niente.
Prima di allora, o con qualche ritocco config non ricordo con precisione, c'era la possibilità di un'eccezione essere gettato da codice non gestito, che non riusciti a far convertire in un oggetto compatibile Exception.
Nota che c'è un'altra opzione in mezzo, in cui si specifica il tipo, ma nessuna variabile:
catch (Exception)
{
...
}
Personalmente sarei molto prudente di cattura un'eccezione senza nemmeno registrazione esso. Potrebbe essere necessario se chiami un'API boneheaded, ma in genere è meglio evitare.
"c'era la possibilità di lanciare un'eccezione dal codice non gestito che non ha ottenuto ..." Quindi dal 2.0 in poi viene convertito in Eccezione compatibile? Ad esempio, ora qualsiasi cosa generata da gestione o non gestita verrà catturata da catch (Exception e) {}. A proposito, ho provato a sperimentare con Outlook Interop Library ma non sono sicuro di come ottenere un errore di codice non gestito lego. – devanalyst
@devanalyst: Sì, I * credo * tutto viene convertito in 'Exception' now. –
@JonSkeet: Ma qual è la differenza tra 'catch',' catch (Exception) 'e' catch (Exception ex) '? Il primo non fa nulla che catturare tutto, il secondo solo il tipo, e il terzo anche i dettagli? Cosa dovresti prendere oltre un'eccezione? – testing
Nel suo secondo esempio è possibile fare riferimento i dati di eccezione, come l'analisi dello stack, fonte, ecc E 'anche dà un messaggio generale che a volte è utile. Ti dice PERCHÉ hai subito un'eccezione importante durante il debug.
Penso che ti sia mancato il punto, il primo cattura tutte le eccezioni, il secondo rileva le eccezioni .NET –
In realtà tutto ciò che chiedevano era quale fosse la differenza tra due esempi di cattura e questa è la differenza. O fai riferimento all'eccezione o non lo fai. E così sai, entrambi gli esempi catturano tutte le eccezioni .Net. Qualsiasi eccezione catturata sarà una "eccezione .Net" perché si tratta di C#. È anche importante notare che tutte le eccezioni hanno la classe Exception nella loro struttura di ereditarietà perché una classe di eccezioni deve ereditarlo direttamente o indirettamente ereditando da un'altra classe che ha ereditato la classe Exception. – jlafay
si sono errati, alcune eccezioni non ereditano da Eccezione. Sono creati da codice utente, o codice C#, ma altri non lo fanno –
In genere è necessario rilevare prima gli errori specifici.
Ma se si va per la cattura di un generale Exception come si fa direi uso secondo caso:
catch (Exception ex)
{
MessageBox.Show("Error.");
//we never use ex, so is it better to use catch without arguments?
}
questo può aiutare con debbuging dal momento che la variabile contiene l'analisi dello stack, messaggio di eccezione .. .eccetera. Che puoi usare per registrare l'errore o qualcosa che ti aiuti a prevenirlo.
essere molto attenti con questo approccio, però:
MessageBox.Show("Error.");
Non tenere traccia dei vostri errori da qualche parte (come un file di log) possono causare davvero un gran casino.
I dati di eccezione sono comunque raggiungibili. Se passi in un'eccezione senza una variabile, verrà visualizzato un simbolo che ti mostrerà i dati delle eccezioni. – GeirGrusom
@GeirGrusom - sì, ma non è possibile utilizzare tali informazioni per l'accesso a un file o qualcosa del genere? – TheBoyan
@GeirGrusom sicuro, è possibile visualizzare l'eccezione quando si esegue il debug, ma non si dispone di un riferimento per l'utilizzo nella registrazione o la visualizzazione del messaggio appropriato all'utente. – DOK
Penso che siano uguali. Ma il secondo caso ha generato un avviso del compilatore perché dichiari un'eccezione che non hai usato. Mi piace piuttosto il primo perché dici esplicitamente che non usi l'eccezione. C'è anche una terza
catch (Exception)
{
//do something
}
se si desidera specificare il tipo di eccezione, ma non si preoccupa l'eccezione stessa.
Questo significa che se viene lanciata un'eccezione, essa entra comunque all'interno del blocco catch, anche se non facciamo nulla con l'eccezione? –
Alcune eccezioni non possono essere rilevate catch(Exception).
Sotto l'ecceczione in mono su linux, dovrebbe prendere senza parametro.
Altrimenti il runtime ignorerà lo stato catch(Exception).
System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
Se si verifica il problema come quello, provare a rimuovere il parametro di catch dichiarazione, log contesto vars per scoprire la causa dell'errore.
P.S. Non so come su Windows, il programma eseguito in Windows è normale.
Leggi questo: http://msdn.microsoft.com/en-us/library/0yd65esw(VS.80).aspx – JonH
Nel secondo caso, utilizzare 'catch (Exception)' se si desidera rilevare quel tipo o tipi derivati di eccezioni, ma non vogliono conoscere i dettagli. Altrimenti riceverai un avviso e dichiarerai una variabile quando non ce n'è una necessaria –