Classe Exception

Rappresenta gli errori che si verificano durante l'esecuzione dell'applicazione.

Spazio dei nomi: System
Assembly: mscorlib (in mscorlib.dll)

Sintassi

'Dichiarazione
<SerializableAttribute> _
<ComVisibleAttribute(True)> _
<ClassInterfaceAttribute(ClassInterfaceType.None)> _
Public Class Exception
    Implements ISerializable, _Exception
'Utilizzo
Dim instance As Exception
[SerializableAttribute] 
[ComVisibleAttribute(true)] 
[ClassInterfaceAttribute(ClassInterfaceType.None)] 
public class Exception : ISerializable, _Exception
[SerializableAttribute] 
[ComVisibleAttribute(true)] 
[ClassInterfaceAttribute(ClassInterfaceType::None)] 
public ref class Exception : ISerializable, _Exception
/** @attribute SerializableAttribute() */ 
/** @attribute ComVisibleAttribute(true) */ 
/** @attribute ClassInterfaceAttribute(ClassInterfaceType.None) */ 
public class Exception implements ISerializable, _Exception
SerializableAttribute 
ComVisibleAttribute(true) 
ClassInterfaceAttribute(ClassInterfaceType.None) 
public class Exception implements ISerializable, _Exception

Note

Questa classe è la classe base per tutte le eccezioni. Quando si verifica un errore, il sistema o l'applicazione in esecuzione lo notifica generando un'eccezione che contiene informazioni relative all'errore. Una volta generata, un'eccezione viene gestita dall'applicazione o dal gestore eccezioni predefinito.

Common Language Runtime comprende un modello di gestione delle eccezioni, basato sulla rappresentazione delle eccezioni come oggetti e sulla separazione del codice di programma e del codice di gestione delle eccezioni rispettivamente in blocchi try e blocchi catch. Possono essere presenti uno o più blocchi catch, ognuno progettato per gestire un particolare tipo di eccezione. In alternativa, può essere presente un blocco creato per intercettare un'eccezione più specifica rispetto a un altro blocco.

Se un'applicazione gestisce le eccezioni che si verificano durante l'esecuzione di un blocco di codice di un'applicazione, il codice deve trovarsi all'interno di un'istruzione try. Il codice dell'applicazione all'interno di un'istruzione try è un blocco try. Il codice dell'applicazione che gestisce le eccezioni generate da un blocco try si trova all'interno di un'istruzione catch e viene detto bloccocatch. A un blocco try sono associati zero o più blocchi catch e ogni blocco catch include un filtro di tipo che determina i tipi di eccezione che verranno gestiti.

Quando si verifica un'eccezione in un blocco try, viene eseguita la ricerca dei blocchi catch nell'ordine in cui appaiono nel codice dell'applicazione, fino a che non viene individuato un blocco catch che gestisce l'eccezione. Un blocco catch gestisce un'eccezione di tipo T se nel filtro di tipo del blocco catch è specificato T o qualsiasi tipo da cui T deriva. La ricerca viene interrotta dopo il rilevamento del primo blocco catch che gestisce l'eccezione. Per questo motivo, nel codice dell'applicazione, un blocco catch che gestisce un tipo deve essere specificato prima di un blocco catch che gestisce i relativi tipi di base, come dimostrato nell'esempio illustrato di seguito in questa sezione. Un blocco catch che gestisce System.Exception viene specificato per ultimo.

Se nessuno dei blocchi catch associati al blocco try corrente gestisce l'eccezione e se il blocco try corrente è nidificato all'interno di altri blocchi try nella chiamata corrente, vengono ricercati i blocchi catch associati al blocco try successivo che li contiene. Se non viene rilevato alcun blocco catch per l'eccezione, viene eseguita la ricerca dei precedenti livelli di nidificazione nella chiamata corrente. Se non viene rilevato alcun blocco catch per l'eccezione nella chiamata corrente, l'eccezione viene passata sullo stack di chiamate e viene eseguita la ricerca di un blocco catch che gestisce l'eccezione nello stack frame precedente. La ricerca dello stack di chiamate continua fino a quando viene gestita l'eccezione o non esistono più frame nello stack di chiamate. Se si raggiunge l'inizio dello stack di chiamate senza che venga rilevato alcun blocco catch che gestisce l'eccezione, questa viene gestita dal gestore eccezioni predefinito e l'applicazione viene terminata.

I tipi di eccezione supportano le seguenti caratteristiche:

  • Testo in formato leggibile in cui viene descritto l'errore. Quando si verifica un'eccezione, il runtime rende disponibile un messaggio di testo per informare l'utente della natura dell'errore e per suggerire come risolvere il problema. Questo messaggio di testo è contenuto nella proprietà Message dell'oggetto eccezione. Durante la creazione dell'oggetto eccezione, è possibile passare una stringa di testo al costruttore per descrivere i dettagli di quella particolare eccezione. Se al costruttore non viene fornito alcun argomento di messaggio di errore, viene utilizzato il messaggio di errore predefinito.

  • Lo stato dello stack di chiamate al momento della generazione dell'eccezione. La proprietà StackTrace riporta un'analisi dello stack che può essere utilizzata per determinare il punto del codice in cui si è verificato l'errore. Nell'analisi dello stack vengono elencati tutti i metodi chiamati e i numeri di riga nel file di origine dove vengono eseguite le chiamate.

Nell'ambito della classe base Exception sono presenti due categorie di eccezioni:

  • Le classi di eccezione già definite di Common Language Runtime derivate da SystemException.

  • Le classi di eccezione dell'applicazione definite dall'utente derivate da ApplicationException.

Exception include diverse proprietà in grado di identificare la posizione del codice, il tipo, il file della Guida e il motivo dell'eccezione: StackTrace, InnerException, Message, HelpLink, HResult, Source, TargetSite e Data.

Se esiste una relazione causa-effetto tra due o più eccezioni, la proprietà InnerException mantiene queste informazioni. L'eccezione esterna viene generata in risposta all'eccezione interna. Il codice che gestisce l'eccezione esterna può utilizzare le informazioni relative all'eccezione interna precedente per gestire l'errore in modo più appropriato. Ulteriori informazioni sull'eccezione possono essere memorizzate nella proprietà Data.

È necessario localizzare la stringa del messaggio di errore passata al costruttore durante la creazione dell'oggetto eccezione; il messaggio può essere fornito da un file di risorsa utilizzando ResourceManager. Per ulteriori informazioni sulle risorse localizzate, vedere i cenni preliminari sullo spazio dei nomi System.Resources e Creazione del package e distribuzione delle risorse.

Per fornire all'utente informazioni relative alla causa dell'eccezione, la proprietà HelpLink può contenere un URL (o URN) di un file della Guida.

Exception utilizza HRESULT COR_E_EXCEPTION, con valore 0x80131500.

Per un elenco dei valori iniziali di proprietà per un'istanza di Exception, vedere i costruttori Exception.

Considerazioni sulle prestazioni

La generazione o la gestione di un'eccezione richiede una notevole quantità di risorse di sistema e tempo di esecuzione. È pertanto consigliabile generare eccezioni solo per gestire condizioni straordinarie e non per gestire eventi prevedibili o per il controllo del flusso. L'applicazione può ad esempio generare un'eccezione se un argomento del metodo non è valido, perché il metodo deve essere chiamato con parametri validi e un argomento di metodo non valido costituisce un evento straordinario. Evitare invece la generazione di eccezioni relative a input utente non valido, perché è possibile prevedere che l'utente potrebbe immettere dati non validi. Per gestire questa eventualità è possibile fornire un meccanismo di ripetizione, per consentire all'utente di immettere dati di input validi.

Generare le eccezioni solo in condizioni straordinarie, quindi intercettarle in un unico gestore di eccezioni generico, che può essere utilizzato per la maggior parte delle eccezioni dell'applicazione, anziché in gestori applicabili solo a eccezioni specifiche. Si consiglia di adottare questo approccio perché la maggior parte degli errori può essere gestita tramite codice di convalida e di gestione degli errori in prossimità dell'errore stesso. Non è pertanto necessario generare o rilevare alcuna eccezione. Il gestore di eccezioni generico rileva le eccezioni realmente impreviste, generate in qualsiasi punto dell'applicazione.

Evitare inoltre di generare eccezioni in tutti i casi in cui è sufficiente un codice restituito. Non convertire un codice restituito in eccezione e non rilevare regolarmente le eccezioni per poi ignorarle e continuare l'elaborazione.

Esempio

Nel seguente esempio di codice viene illustrato un blocco catch definito per gestire errori ArithmeticException. Questo blocco catch rileva anche errori DivideByZeroException dal momento che DivideByZeroException deriva da ArithmeticException e non esiste alcun blocco catch esplicitamente definito per errori DivideByZeroException.

Imports System

Class ExceptionTestClass
   
   Public Shared Sub Main()
      Dim x As Integer = 0
      Try
         Dim y As Integer = 100 / x
      Catch e As ArithmeticException
         Console.WriteLine("ArithmeticException Handler: {0}", e.ToString())
      Catch e As Exception
         Console.WriteLine("Generic Exception Handler: {0}", e.ToString())
      End Try
   End Sub 'Main
End Class 'ExceptionTestClass
using System;

class ExceptionTestClass 
{
public static void Main() 
{
   int x = 0;
      try 
      {
         int y = 100/x;
      }
         catch (ArithmeticException e) 
         {
         Console.WriteLine("ArithmeticException Handler: {0}", e.ToString());
         }
            catch (Exception e) 
            {
            Console.WriteLine("Generic Exception Handler: {0}", e.ToString());
            }
      } 
}
using namespace System;
int main()
{
   int x = 0;
   try
   {
      int y = 100 / x;
   }
   catch ( ArithmeticException^ e ) 
   {
      Console::WriteLine( "ArithmeticException Handler: {0}", e );
   }
   catch ( Exception^ e ) 
   {
      Console::WriteLine( "Generic Exception Handler: {0}", e );
   }

}
import System.*;

class ExceptionTestClass
{
    public static void main(String[] args)
    {
        int x = 0;
        try {
            int y = 100 / x;
        }
        catch (ArithmeticException e) {
            Console.WriteLine("ArithmeticException Handler: {0}", e.ToString());
        }
        catch (System.Exception e) {
            Console.WriteLine("Generic Exception Handler: {0}", e.ToString());
        }
    } //main
} //ExceptionTestClass

Il codice C# ha il seguente output:

ArithmeticException Handler: System.DivideByZeroException: Attempted to divide by zero. at ExceptionTestClass.Main()

Il codice Visual Basic ha il seguente output:

ArithmeticException Handler: System.OverflowException: Exception of type System.OverflowException was thrown. at ExceptionTestClass.Main()

Gerarchia di ereditarietà

System.Object
  System.Exception
     Classi derivate

Codice thread safe

I membri statici pubblici (Shared in Visual Basic) di questo tipo sono validi per le operazioni multithreading. I membri di istanza non sono garantiti come thread safe.

Piattaforme

Windows 98, Windows 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile per Pocket PC, Windows Mobile per Smartphone, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition

.NET Framework non supporta tutte le versioni di ciascuna piattaforma. Per un elenco delle versioni supportate, vedere Requisiti di sistema.

Informazioni sulla versione

.NET Framework

Supportato in: 2.0 1.1 1.0

.NET Compact Framework

Supportato in: 2.0 1.0

Vedere anche

Riferimenti

Membri Exception
Spazio dei nomi System
SystemException
Classe ApplicationException

Altre risorse

Gestione e generazione di eccezioni
Creazione del package e distribuzione delle risorse