Perché non esiste una chiave specificata con .NET KeyNotFoundException?

Questa potrebbe non essere la risposta ufficiale, ma ...

C # e VB.NET - i principali linguaggi .NET - sono lingue tipizzate staticamente (sì, lo so, supportano la digitazione dinamica, ma comunque). Ciò significa che le proprietà nelle classi sono state digitate. Quale sarebbe il tipo di KeyNotFoundException.Key ?

Dictionary<string, string> dict1 = new Dictionary<string, string>();
try
{
    Console.WriteLine(dict1["one"]);
}
catch (KeyNotFoundException e)
{
    // is e.Key a string?
}

Dictionary<int, int> dict2 = new Dictionary<int, int>();
try
{
    Console.WriteLine(dict2[1]);
}
catch (KeyNotFoundException e)
{
    // is e.Key an int?
}

Se vuoi supportare correttamente questo, dovresti usare i generici - KeyNotFoundException<string> e KeyNotFoundException<int> . Ma questo complicherebbe l'API solo così puoi ottenere le informazioni che già possiedi.

Questa domanda richiede di scavare nella storia del design di .NET Framework. In quanto tale,

• Le persone che hanno effettivamente lavorato nel team di progettazione di .NET Framework sarebbero in grado di fornire un account di prima mano autorevole di questa domanda;
• Le persone che non hanno accesso a loro non sarebbero in grado di fornire un account di prima mano. Tutto quello che potremmo fare è indovinare.

Ammetto che non lo sono, quindi la mia risposta a questa domanda si basa sulla supposizione.

In generale, questa domanda non si adatta bene a questo sito. È meglio porre questa domanda direttamente di fronte a un ex membro del team di progettazione .NET Framework.

Esamineremo alcune cose qui.

Disponibile da .NET Framework 1.1:

• System.ArgumentOutOfRangeException class
  • Costruttori
  • ActualValue property

Disponibile da .NET Framework 2.0:

• System.Collections.Generic.KeyNotFoundException class

Modifiche apportate alle classi esistenti da .NET Framework 2.0:

• proprietà (System.Exception).Data

Spiegazione del comportamento degli argomenti non validi in Dictionary indicizzatore:

• link
  • Genera ArgumentNullException quando la chiave è nullo.
  • Genera KeyNotFoundException quando la chiave non esiste nella collezione.

Possiamo vedere che, KeyNotFoundException è stato effettivamente aggiunto a .NET Framework in un secondo momento rispetto a ArgumentOutOfRangeException . In altre parole, è possibile che sia stata deliberata la decisione di omettere la memorizzazione della chiave nell'oggetto eccezione.

Alcune supposizioni sono:

• Forse era un problema di sicurezza? Il timore di un codice di basso livello che incontra un problema non trovato, l'archiviazione della chiave nell'eccezione generata e il chiamante di livello superiore ha avuto la possibilità di vedere la chiave, rivelando così le implementazioni nel codice di basso livello? Tali preoccupazioni sono state sollevate quando la proprietà (System.Exception).Data è stata aggiunta in .NET Framework 2.0.

• Forse era un problema di boxe? Quando un tipo non di riferimento (ad esempio un C # struct ) viene memorizzato in un campo di tipo object ( System.Object ), boxing si verifica . Viene creato un nuovo oggetto per boxare la struct, quindi il valore della struct viene copiato nella casella.

• Forse era un bisogno (linea guida) di lanciare un'eccezione di un tipo diverso? Le linee guida di Microsoft invitano a lanciare diversi tipi di tipi di per ragioni diverse (differenzianti). Chiamando il% gdo dell'indicatore Dictionary con null genera un ArgumentNullException , quindi chiamandolo con una chiave non nulla che non esiste in quella raccolta deve lanciare qualcosa di diverso?

Trattandosi di congetture, queste ipotesi sono probabilmente errate e potremmo non saperlo mai.