Classe System.Exception

Questo articolo fornisce osservazioni supplementari alla documentazione di riferimento per questa API.

La Exception classe è la classe base per tutte le eccezioni. Quando si verifica un errore, il sistema o l'applicazione attualmente in esecuzione lo segnala generando un'eccezione che contiene informazioni sull'errore. Dopo la generazione di un'eccezione, viene gestita dall'applicazione o dal gestore eccezioni predefinito.

Errori ed eccezioni

Gli errori di runtime possono verificarsi per diversi motivi. Tuttavia, non tutti gli errori devono essere gestiti come eccezioni nel codice. Ecco alcune categorie di errori che possono verificarsi in fase di esecuzione e i modi appropriati per rispondere a tali errori.

• Errori di utilizzo. Un errore di utilizzo rappresenta un errore nella logica del programma che può generare un'eccezione. Tuttavia, l'errore deve essere risolto non tramite la gestione delle eccezioni, ma modificando il codice difettoso. Ad esempio, l'override del Object.Equals(Object) metodo nell'esempio seguente presuppone che l'argomento obj sia sempre diverso da null.

  using System;
  
  public class Person1
  {
     private string _name;
  
     public string Name
     {
        get { return _name; }
        set { _name = value; }
     }
  
     public override int GetHashCode()
     {
        return this.Name.GetHashCode();
     }
  
     public override bool Equals(object obj)
     {
        // This implementation contains an error in program logic:
        // It assumes that the obj argument is not null.
        Person1 p = (Person1) obj;
        return this.Name.Equals(p.Name);
     }
  }
  
  public class UsageErrorsEx1
  {
     public static void Main()
     {
        Person1 p1 = new Person1();
        p1.Name = "John";
        Person1 p2 = null;
  
        // The following throws a NullReferenceException.
        Console.WriteLine("p1 = p2: {0}", p1.Equals(p2));
     }
  }
  

  Eccezione NullReferenceException che determina quando obj è null possibile eliminare modificando il codice sorgente per testare in modo esplicito i valori Null prima di chiamare l'override e quindi ripetere la Object.Equals compilazione. L'esempio seguente contiene il codice sorgente corretto che gestisce un null argomento.

  using System;
  
  public class Person2
  {
      private string _name;
  
      public string Name
      {
          get { return _name; }
          set { _name = value; }
      }
  
      public override int GetHashCode()
      {
          return this.Name.GetHashCode();
      }
  
      public override bool Equals(object obj)
      {
          // This implementation handles a null obj argument.
          Person2 p = obj as Person2;
          if (p == null)
              return false;
          else
              return this.Name.Equals(p.Name);
      }
  }
  
  public class UsageErrorsEx2
  {
      public static void Main()
      {
          Person2 p1 = new Person2();
          p1.Name = "John";
          Person2 p2 = null;
  
          Console.WriteLine("p1 = p2: {0}", p1.Equals(p2));
      }
  }
  // The example displays the following output:
  //        p1 = p2: False
  

  Anziché usare la gestione delle eccezioni per gli errori di utilizzo, è possibile usare il Debug.Assert metodo per identificare gli errori di utilizzo nelle compilazioni di debug e il Trace.Assert metodo per identificare gli errori di utilizzo nelle build di debug e versione. Per ulteriori informazioni, vedere Asserzioni nel metodo gestito.

• Errori del programma. Un errore di programma è un errore di run-time che non può essere necessariamente evitato scrivendo codice privo di bug.

  In alcuni casi, un errore del programma può riflettere una condizione di errore prevista o di routine. In questo caso, è consigliabile evitare di usare la gestione delle eccezioni per gestire l'errore del programma e ripetere l'operazione. Se, ad esempio, si prevede che l'utente inserisca una data in un formato specifico, è possibile analizzare la stringa di data chiamando il DateTime.TryParseExact metodo , che restituisce un Boolean valore che indica se l'operazione di analisi ha avuto esito positivo, anziché usare il DateTime.ParseExact metodo , che genera un'eccezione FormatException se la stringa di data non può essere convertita in un DateTime valore. Analogamente, se un utente tenta di aprire un file che non esiste, è prima possibile chiamare il File.Exists metodo per verificare se il file esiste e, in caso contrario, chiedere all'utente se vuole crearlo.

  In altri casi, un errore del programma riflette una condizione di errore imprevista che può essere gestita nel codice. Ad esempio, anche se è stato controllato per assicurarsi che esista un file, potrebbe essere eliminato prima di poterlo aprire oppure potrebbe essere danneggiato. In tal caso, il tentativo di aprire il file creando un'istanza di un StreamReader oggetto o chiamando il metodo può generare un'eccezione OpenFileNotFoundException . In questi casi, è consigliabile usare la gestione delle eccezioni per il ripristino dall'errore.

• Errori di sistema. Un errore di sistema è un errore di runtime che non può essere gestito a livello di codice in modo significativo. Ad esempio, qualsiasi metodo può generare un'eccezione OutOfMemoryException se Common Language Runtime non è in grado di allocare memoria aggiuntiva. In genere, gli errori di sistema non vengono gestiti tramite la gestione delle eccezioni. Potrebbe invece essere possibile usare un evento, AppDomain.UnhandledException ad esempio e chiamare il Environment.FailFast metodo per registrare le informazioni sulle eccezioni e notificare all'utente l'errore prima che l'applicazione termini.

Blocchi try/catch

Common Language Runtime fornisce un modello di gestione delle eccezioni basato sulla rappresentazione delle eccezioni come oggetti e sulla separazione del codice del programma e della gestione delle eccezioni in try blocchi e catch blocchi. Possono essere presenti uno o più catch blocchi, ognuno progettato per gestire un particolare tipo di eccezione o un blocco progettato 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 dell'applicazione, il codice deve essere inserito all'interno di un'istruzione try e viene chiamato try blocco. Il codice dell'applicazione che gestisce le eccezioni generate da un try blocco viene inserito all'interno di un'istruzione catch e viene chiamato catch blocco. Zero o più catch blocchi sono associati a un try blocco e ogni catch blocco include un filtro di tipo che determina i tipi di eccezioni gestite.

Quando si verifica un'eccezione in un try blocco, il sistema cerca i blocchi associati catch nell'ordine in cui vengono visualizzati nel codice dell'applicazione finché non individua un catch blocco che gestisce l'eccezione. Un catch blocco gestisce un'eccezione di tipo T se il filtro di tipo del blocco catch specifica T o qualsiasi tipo che T deriva da . Il sistema smette di eseguire la ricerca dopo aver trovato il primo catch blocco che gestisce l'eccezione. Per questo motivo, nel codice dell'applicazione, è necessario specificare un catch blocco che gestisce un tipo prima di un catch blocco che gestisce i relativi tipi di base, come illustrato nell'esempio che segue questa sezione. Blocco catch specificato System.Exception per ultimo.

Se nessuno dei blocchi associati al blocco corrente try gestisce l'eccezione e il blocco corrente try viene annidato all'interno di catch altri try blocchi nella chiamata corrente, vengono cercati i catch blocchi associati al blocco di inclusione try successivo. Se non viene trovato alcun catch blocco per l'eccezione, il sistema cerca i livelli di annidamento precedenti nella chiamata corrente. Se non viene trovato alcun catch blocco per l'eccezione nella chiamata corrente, l'eccezione viene passata allo stack di chiamate e viene eseguita la ricerca del frame dello stack precedente per un catch blocco che gestisce l'eccezione. La ricerca dello stack di chiamate continua fino a quando l'eccezione non viene gestita o fino a quando non esistono più frame nello stack di chiamate. Se la parte superiore dello stack di chiamate viene raggiunta senza trovare un catch blocco che gestisce l'eccezione, il gestore di eccezioni predefinito lo gestisce e l'applicazione termina.

F# try.. con expression

F# non usa catch blocchi. Al contrario, un'eccezione generata viene confrontata con un singolo with blocco. Poiché si tratta di un'espressione, anziché di un'istruzione, tutti i percorsi devono restituire lo stesso tipo. Per altre informazioni, vedere La prova... con Espressione.

Caratteristiche del tipo di eccezione

I tipi di eccezione supportano le funzionalità seguenti:

• Testo leggibile che descrive l'errore. Quando si verifica un'eccezione, il runtime rende disponibile un sms per informare l'utente della natura dell'errore e suggerire un'azione per risolvere il problema. Questo messaggio di testo viene mantenuto nella Message proprietà dell'oggetto eccezione. Durante la creazione dell'oggetto eccezione, è possibile passare una stringa di testo al costruttore per descrivere i dettagli di tale eccezione specifica. Se non viene fornito alcun argomento del messaggio di errore al costruttore, viene utilizzato il messaggio di errore predefinito. Per altre informazioni, vedere la proprietà Message.

• Stato dello stack di chiamate quando è stata generata l'eccezione. La StackTrace proprietà contiene una traccia dello stack che può essere usata per determinare dove si verifica l'errore nel codice. L'analisi dello stack elenca tutti i metodi chiamati e i numeri di riga nel file di origine in cui vengono effettuate le chiamate.

Proprietà della classe di eccezione

La Exception classe include una serie di proprietà che consentono di identificare il percorso del codice, il tipo, il file della Guida e il motivo dell'eccezione: StackTrace, MessageInnerException, HelpLink, HResultSourceTargetSite, e .Data

Quando esiste una relazione causale tra due o più eccezioni, la InnerException proprietà mantiene queste informazioni. L'eccezione esterna viene generata in risposta a questa eccezione interna. Il codice che gestisce l'eccezione esterna può usare le informazioni dell'eccezione interna precedente per gestire l'errore in modo più appropriato. Le informazioni supplementari sull'eccezione possono essere archiviate come raccolta di coppie chiave/valore nella Data proprietà .

La stringa del messaggio di errore passata al costruttore durante la creazione dell'oggetto eccezione deve essere localizzata e può essere fornita da un file di risorse usando la ResourceManager classe . Per altre informazioni sulle risorse localizzate, vedere gli argomenti Creazione di assembly satellite e creazione di pacchetti e distribuzione di risorse .

Per fornire all'utente informazioni complete sul motivo per cui si è verificata l'eccezione, la HelpLink proprietà può contenere un URL (o UN URN) in un file della Guida.

La Exception classe usa HRESULT COR_E_EXCEPTION, che ha il valore 0x80131500.

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

Considerazioni sulle prestazioni

La generazione o la gestione di un'eccezione utilizza una quantità significativa di risorse di sistema e tempo di esecuzione. Genera eccezioni solo per gestire condizioni davvero straordinarie, non per gestire eventi prevedibili o controllo del flusso. Ad esempio, in alcuni casi, ad esempio quando si sviluppa una libreria di classi, è ragionevole generare un'eccezione se un argomento del metodo non è valido, perché si prevede che il metodo venga chiamato con parametri validi. Un argomento del metodo non valido, se non è il risultato di un errore di utilizzo, significa che si è verificato un evento straordinario. Viceversa, non generare un'eccezione se l'input dell'utente non è valido, perché è possibile prevedere che gli utenti immettano occasionalmente dati non validi. Fornire invece un meccanismo di ripetizione dei tentativi in modo che gli utenti possano immettere un input valido. Né è consigliabile usare le eccezioni per gestire gli errori di utilizzo. Usare invece le asserzioni per identificare e correggere gli errori di utilizzo.

Inoltre, non generare un'eccezione quando un codice restituito è sufficiente; non convertire un codice restituito in un'eccezione; e non intercettare regolarmente un'eccezione, ignorarla e quindi continuare l'elaborazione.

Generare nuovamente un'eccezione

In molti casi, un gestore eccezioni vuole semplicemente passare l'eccezione al chiamante. Questo avviene più spesso in:

• Libreria di classi che a sua volta esegue il wrapping delle chiamate ai metodi nella libreria di classi .NET o in altre librerie di classi.

• Applicazione o libreria che rileva un'eccezione irreversibile. Il gestore eccezioni può registrare l'eccezione e quindi generare nuovamente l'eccezione.

Il modo consigliato per generare nuovamente un'eccezione consiste nell'usare semplicemente l'istruzione throw in C#, la funzione reraise in F# e l'istruzione Throw in Visual Basic senza includere un'espressione. In questo modo, tutte le informazioni sullo stack di chiamate vengono mantenute quando l'eccezione viene propagata al chiamante. Ciò è illustrato nell'esempio seguente. Un metodo di estensione stringa, FindOccurrences, esegue il wrapping di una o più chiamate a String.IndexOf(String, Int32) senza convalidare gli argomenti in anticipo.

using System;
using System.Collections.Generic;

public static class Library1
{
    public static int[] FindOccurrences(this String s, String f)
    {
        var indexes = new List<int>();
        int currentIndex = 0;
        try
        {
            while (currentIndex >= 0 && currentIndex < s.Length)
            {
                currentIndex = s.IndexOf(f, currentIndex);
                if (currentIndex >= 0)
                {
                    indexes.Add(currentIndex);
                    currentIndex++;
                }
            }
        }
        catch (ArgumentNullException)
        {
            // Perform some action here, such as logging this exception.

            throw;
        }
        return indexes.ToArray();
    }
}

Un chiamante chiama FindOccurrences quindi due volte. Nella seconda chiamata a FindOccurrences, il chiamante passa un oggetto null come stringa di ricerca, che fa sì che il String.IndexOf(String, Int32) metodo generi un'eccezione ArgumentNullException . Questa eccezione viene gestita dal FindOccurrences metodo e passata di nuovo al chiamante. Poiché l'istruzione throw viene usata senza espressione, l'output dell'esempio mostra che lo stack di chiamate viene mantenuto.

public class RethrowEx1
{
    public static void Main()
    {
        String s = "It was a cold day when...";
        int[] indexes = s.FindOccurrences("a");
        ShowOccurrences(s, "a", indexes);
        Console.WriteLine();

        String toFind = null;
        try
        {
            indexes = s.FindOccurrences(toFind);
            ShowOccurrences(s, toFind, indexes);
        }
        catch (ArgumentNullException e)
        {
            Console.WriteLine("An exception ({0}) occurred.",
                              e.GetType().Name);
            Console.WriteLine("Message:\n   {0}\n", e.Message);
            Console.WriteLine("Stack Trace:\n   {0}\n", e.StackTrace);
        }
    }

    private static void ShowOccurrences(String s, String toFind, int[] indexes)
    {
        Console.Write("'{0}' occurs at the following character positions: ",
                      toFind);
        for (int ctr = 0; ctr < indexes.Length; ctr++)
            Console.Write("{0}{1}", indexes[ctr],
                          ctr == indexes.Length - 1 ? "" : ", ");

        Console.WriteLine();
    }
}
// The example displays the following output:
//    'a' occurs at the following character positions: 4, 7, 15
//
//    An exception (ArgumentNullException) occurred.
//    Message:
//       Value cannot be null.
//    Parameter name: value
//
//    Stack Trace:
//          at System.String.IndexOf(String value, Int32 startIndex, Int32 count, Stri
//    ngComparison comparisonType)
//       at Library.FindOccurrences(String s, String f)
//       at Example.Main()

Al contrario, se l'eccezione viene generata nuovamente usando questa istruzione:

throw e;

... quindi lo stack di chiamate completo non viene mantenuto e l'esempio genera l'output seguente:

'a' occurs at the following character positions: 4, 7, 15

An exception (ArgumentNullException) occurred.
Message:
   Value cannot be null.
Parameter name: value

Stack Trace:
      at Library.FindOccurrences(String s, String f)
   at Example.Main()

Un'alternativa leggermente più complessa consiste nel generare una nuova eccezione e mantenere le informazioni sullo stack di chiamate dell'eccezione originale in un'eccezione interna. Il chiamante può quindi usare la proprietà della InnerException nuova eccezione per recuperare lo stack frame e altre informazioni sull'eccezione originale. In questo caso, l'istruzione throw è:

throw new ArgumentNullException("You must supply a search string.", e);

Il codice utente che gestisce l'eccezione deve sapere che la InnerException proprietà contiene informazioni sull'eccezione originale, come illustrato dal gestore eccezioni seguente.

try
{
    indexes = s.FindOccurrences(toFind);
    ShowOccurrences(s, toFind, indexes);
}
catch (ArgumentNullException e)
{
    Console.WriteLine("An exception ({0}) occurred.",
                      e.GetType().Name);
    Console.WriteLine("   Message:\n{0}", e.Message);
    Console.WriteLine("   Stack Trace:\n   {0}", e.StackTrace);
    Exception ie = e.InnerException;
    if (ie != null)
    {
        Console.WriteLine("   The Inner Exception:");
        Console.WriteLine("      Exception Name: {0}", ie.GetType().Name);
        Console.WriteLine("      Message: {0}\n", ie.Message);
        Console.WriteLine("      Stack Trace:\n   {0}\n", ie.StackTrace);
    }
}
// The example displays the following output:
//    'a' occurs at the following character positions: 4, 7, 15
//
//    An exception (ArgumentNullException) occurred.
//       Message: You must supply a search string.
//
//       Stack Trace:
//          at Library.FindOccurrences(String s, String f)
//       at Example.Main()
//
//       The Inner Exception:
//          Exception Name: ArgumentNullException
//          Message: Value cannot be null.
//    Parameter name: value
//
//          Stack Trace:
//          at System.String.IndexOf(String value, Int32 startIndex, Int32 count, Stri
//    ngComparison comparisonType)
//       at Library.FindOccurrences(String s, String f)

Scegliere le eccezioni standard

Quando è necessario generare un'eccezione, è spesso possibile usare un tipo di eccezione esistente in .NET anziché implementare un'eccezione personalizzata. È consigliabile usare un tipo di eccezione standard in queste due condizioni:

• Si sta generando un'eccezione causata da un errore di utilizzo, ovvero da un errore nella logica del programma eseguita dallo sviluppatore che chiama il metodo . In genere, si genererebbe un'eccezione, ArgumentExceptionad esempio , ArgumentNullException, InvalidOperationExceptiono NotSupportedException. La stringa specificata al costruttore dell'oggetto eccezione durante la creazione di un'istanza dell'oggetto eccezione deve descrivere l'errore in modo che lo sviluppatore possa correggerlo. Per altre informazioni, vedere la proprietà Message.

• Si sta gestendo un errore che può essere comunicato al chiamante con un'eccezione .NET esistente. È consigliabile generare l'eccezione più derivata possibile. Ad esempio, se un metodo richiede che un argomento sia un membro valido di un tipo di enumerazione, è necessario generare un InvalidEnumArgumentException oggetto (la classe più derivata) anziché un oggetto ArgumentException.

Nella tabella seguente sono elencati i tipi di eccezione comuni e le condizioni in cui vengono generate.

Eccezione	Condizione
ArgumentException	Un argomento non Null passato a un metodo non è valido.
ArgumentNullException	Un argomento passato a un metodo è null.
ArgumentOutOfRangeException	Un argomento non rientra nell'intervallo di valori validi.
DirectoryNotFoundException	Parte di un percorso di directory non è valida.
DivideByZeroException	Il denominatore in un'operazione di divisione o Decimal integer è zero.
DriveNotFoundException	Un'unità non è disponibile o non esiste.
FileNotFoundException	Un file non esiste.
FormatException	Un valore non è in un formato appropriato da convertire da una stringa da un metodo di conversione, Parsead esempio .
IndexOutOfRangeException	Un indice non rientra nei limiti di una matrice o di una raccolta.
InvalidOperationException	Una chiamata al metodo non è valida nello stato corrente di un oggetto.
KeyNotFoundException	Impossibile trovare la chiave specificata per l'accesso a un membro in una raccolta.
NotImplementedException	Un metodo o un'operazione non viene implementato.
NotSupportedException	Un metodo o un'operazione non è supportato.
ObjectDisposedException	Un'operazione viene eseguita su un oggetto eliminato.
OverflowException	Un'operazione aritmetica, di cast o di conversione comporta un overflow.
PathTooLongException	Un percorso o un nome di file supera la lunghezza massima definita dal sistema.
PlatformNotSupportedException	L'operazione non è supportata nella piattaforma corrente.
RankException	Una matrice con il numero errato di dimensioni viene passata a un metodo.
TimeoutException	L'intervallo di tempo assegnato a un'operazione è scaduto.
UriFormatException	Viene usato un URI (Uniform Resource Identifier) non valido.

Implementare eccezioni personalizzate

Nei casi seguenti, l'uso di un'eccezione .NET esistente per gestire una condizione di errore non è adeguata:

• Quando l'eccezione riflette un errore di programma univoco che non può essere mappato a un'eccezione .NET esistente.

• Quando l'eccezione richiede la gestione diversa dalla gestione appropriata per un'eccezione .NET esistente oppure l'eccezione deve essere disambiguata da un'eccezione simile. Ad esempio, se si genera un'eccezione ArgumentOutOfRangeException durante l'analisi della rappresentazione numerica di una stringa non compreso nell'intervallo del tipo integrale di destinazione, non si vuole usare la stessa eccezione per un errore risultante dal chiamante che non fornisce i valori vincolati appropriati quando si chiama il metodo .

La Exception classe è la classe base di tutte le eccezioni in .NET. Molte classi derivate si basano sul comportamento ereditato dei membri della Exception classe e non eseguono l'override dei membri di Exception, né definiscono membri univoci.

Per definire la propria classe di eccezione:

1. Definire una classe che eredita da Exception. Se necessario, definire eventuali membri univoci necessari per la classe per fornire informazioni aggiuntive sull'eccezione. Ad esempio, la ArgumentException classe include una ParamName proprietà che specifica il nome del parametro il cui argomento ha causato l'eccezione e la RegexMatchTimeoutException proprietà include una MatchTimeout proprietà che indica l'intervallo di timeout.

2. Se necessario, eseguire l'override di tutti i membri ereditati la cui funzionalità si desidera modificare o modificare. Si noti che la maggior parte delle classi derivate esistenti di Exception non esegue l'override del comportamento dei membri ereditati.

3. Determinare se l'oggetto eccezione personalizzato è serializzabile. La serializzazione consente di salvare informazioni sull'eccezione e di consentire la condivisione delle informazioni sulle eccezioni da parte di un server e di un proxy client in un contesto di comunicazione remota. Per rendere serializzabile l'oggetto eccezione, contrassegnarlo con l'attributo SerializableAttribute .

4. Definire i costruttori della classe di eccezione. In genere, le classi di eccezioni hanno uno o più costruttori seguenti:

   • Exception(), che usa i valori predefiniti per inizializzare le proprietà di un nuovo oggetto eccezione.

   • Exception(String), che inizializza un nuovo oggetto eccezione con un messaggio di errore specificato.

   • Exception(String, Exception), che inizializza un nuovo oggetto eccezione con un messaggio di errore e un'eccezione interna specificati.

   • Exception(SerializationInfo, StreamingContext), che è un protected costruttore che inizializza un nuovo oggetto eccezione dai dati serializzati. È consigliabile implementare questo costruttore se si è scelto di rendere serializzabile l'oggetto eccezione.

Nell'esempio seguente viene illustrato l'uso di una classe di eccezione personalizzata. Definisce un'eccezione NotPrimeException generata quando un client tenta di recuperare una sequenza di numeri primi specificando un numero iniziale non primo. L'eccezione definisce una nuova proprietà , NonPrime, che restituisce il numero non primo che ha causato l'eccezione. Oltre a implementare un costruttore senza parametri protetto e un costruttore con SerializationInfo parametri e StreamingContext per la serializzazione, la NotPrimeException classe definisce tre costruttori aggiuntivi per supportare la NonPrime proprietà. Ogni costruttore chiama un costruttore della classe base oltre a mantenere il valore del numero non primo. La NotPrimeException classe è contrassegnata anche con l'attributo SerializableAttribute .

using System;
using System.Runtime.Serialization;

[Serializable()]
public class NotPrimeException : Exception
{
   private int notAPrime;

   protected NotPrimeException()
      : base()
   { }

   public NotPrimeException(int value) :
      base(String.Format("{0} is not a prime number.", value))
   {
      notAPrime = value;
   }

   public NotPrimeException(int value, string message)
      : base(message)
   {
      notAPrime = value;
   }

   public NotPrimeException(int value, string message, Exception innerException) :
      base(message, innerException)
   {
      notAPrime = value;
   }

   protected NotPrimeException(SerializationInfo info,
                               StreamingContext context)
      : base(info, context)
   { }

   public int NonPrime
   { get { return notAPrime; } }
}

La PrimeNumberGenerator classe illustrata nell'esempio seguente usa il Sieve di Eratosthenes per calcolare la sequenza di numeri primi da 2 a un limite specificato dal client nella chiamata al relativo costruttore di classe. Il GetPrimesFrom metodo restituisce tutti i numeri primi maggiori o uguali a un limite inferiore specificato, ma genera un'eccezione NotPrimeException se tale limite inferiore non è un numero primo.

using System;
using System.Collections.Generic;

[Serializable]
public class PrimeNumberGenerator
{
   private const int START = 2;
   private int maxUpperBound = 10000000;
   private int upperBound;
   private bool[] primeTable;
   private List<int> primes = new List<int>();

   public PrimeNumberGenerator(int upperBound)
   {
      if (upperBound > maxUpperBound)
      {
         string message = String.Format(
                           "{0} exceeds the maximum upper bound of {1}.",
                           upperBound, maxUpperBound);
         throw new ArgumentOutOfRangeException(message);
      }
      this.upperBound = upperBound;
      // Create array and mark 0, 1 as not prime (True).
      primeTable = new bool[upperBound + 1];
      primeTable[0] = true;
      primeTable[1] = true;

      // Use Sieve of Eratosthenes to determine prime numbers.
      for (int ctr = START; ctr <= (int)Math.Ceiling(Math.Sqrt(upperBound));
            ctr++)
      {
         if (primeTable[ctr]) continue;

         for (int multiplier = ctr; multiplier <= upperBound / ctr; multiplier++)
            if (ctr * multiplier <= upperBound) primeTable[ctr * multiplier] = true;
      }
      // Populate array with prime number information.
      int index = START;
      while (index != -1)
      {
         index = Array.FindIndex(primeTable, index, (flag) => !flag);
         if (index >= 1)
         {
            primes.Add(index);
            index++;
         }
      }
   }

   public int[] GetAllPrimes()
   {
      return primes.ToArray();
   }

   public int[] GetPrimesFrom(int prime)
   {
      int start = primes.FindIndex((value) => value == prime);
      if (start < 0)
         throw new NotPrimeException(prime, String.Format("{0} is not a prime number.", prime));
      else
         return primes.FindAll((value) => value >= prime).ToArray();
   }
}

Nell'esempio seguente vengono effettuate due chiamate al GetPrimesFrom metodo con numeri non primi, uno dei quali supera i limiti del dominio applicazione. In entrambi i casi, l'eccezione viene generata e gestita correttamente nel codice client.

using System;
using System.Reflection;

class Example1
{
    public static void Main()
    {
        int limit = 10000000;
        PrimeNumberGenerator primes = new PrimeNumberGenerator(limit);
        int start = 1000001;
        try
        {
            int[] values = primes.GetPrimesFrom(start);
            Console.WriteLine("There are {0} prime numbers from {1} to {2}",
                              start, limit);
        }
        catch (NotPrimeException e)
        {
            Console.WriteLine("{0} is not prime", e.NonPrime);
            Console.WriteLine(e);
            Console.WriteLine("--------");
        }

        AppDomain domain = AppDomain.CreateDomain("Domain2");
        PrimeNumberGenerator gen = (PrimeNumberGenerator)domain.CreateInstanceAndUnwrap(
                                          typeof(Example).Assembly.FullName,
                                          "PrimeNumberGenerator", true,
                                          BindingFlags.Default, null,
                                          new object[] { 1000000 }, null, null);
        try
        {
            start = 100;
            Console.WriteLine(gen.GetPrimesFrom(start));
        }
        catch (NotPrimeException e)
        {
            Console.WriteLine("{0} is not prime", e.NonPrime);
            Console.WriteLine(e);
            Console.WriteLine("--------");
        }
    }
}

Esempi

Nell'esempio seguente viene illustrato un catch blocco (with in F#) definito per gestire ArithmeticException gli errori. Questo catch blocco intercetta DivideByZeroException anche gli errori, perché DivideByZeroException deriva da ArithmeticException e non esiste alcun catch blocco definito in modo esplicito per DivideByZeroException gli errori.

using System;

class ExceptionTestClass
{
   public static void Main()
   {
      int x = 0;
      try
      {
         int y = 100 / x;
      }
      catch (ArithmeticException e)
      {
         Console.WriteLine($"ArithmeticException Handler: {e}");
      }
      catch (Exception e)
      {
         Console.WriteLine($"Generic Exception Handler: {e}");
      }
   }	
}
/*
This code example produces the following results:

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

*/