2010-07-29 5 views
5

Kann ein Exception-Objekt aufgrund seines internen Fehlers eine andere Exception auslösen?Kann ein Exception-Objekt aufgrund seines internen Fehlers eine andere Ausnahme auslösen?

Angenommen, in try-catch wir instanziieren Exception-Objekt, ist es möglich, die Instanziierung eine weitere Ausnahme auslösen? Wenn ja, müssen wir unendlich viele Try-Catch-Blöcke verschachteln, die so lustig aussehen.

+0

Können Sie Ihre Frage clearify. Ist es, wenn die Ausnahme neu erstellt wird? Liegt es im Catch-Block? –

+0

Bitte sehen Sie meine Modifikation oben. Vielen Dank. – xport

+1

Denken Sie daran. Nicht jede Ausnahme kann und sollte behandelt werden. Einige sind Anzeichen für falsche Logik oder Fehler. –

Antwort

3

Kurz gesagt, die Antwort ist ja, es ist möglich.

Beispiel: Wenn die Ausnahmeklasse erfordert, dass ein großes Objekt als ein Feld initialisiert wird, aber nicht genügend Speicher vorhanden ist, um es zuzuweisen, erhalten Sie ein Ausnahmeobjekt, das eine OutOfMemoryException auslöst.

Ausnahmen sind wie jede andere Klasse und können selbst Ausnahmen auslösen. Es gibt nichts in der Sprache, das es nicht erlaubt.

Ich würde jedoch sagen, dass das Auslösen von Ausnahmen von einer Ausnahmeklasse es schlechte Übung und sollte in der Regel vermieden werden.


Update: (folgende aktualisierte Frage)

Falls Sie ein Ausnahmeobjekt in einem try Block instanziieren, die catch wird es fangen (vorausgesetzt, es fängt die geeignete Art von Ausnahme). Wenn Sie es in den Block catch instanziieren, können Sie dies in einem verschachtelten try{}catch{} tun - das ist ganz normal für Code in einem catch-Block, der Ausnahmen auslösen kann.

Wie andere gesagt haben - einige Ausnahmen sollten nicht abgefangen werden (zum Beispiel OutOfMemory oder unerwartet StackOverflow), da Sie keine Möglichkeit haben, mit ihnen umzugehen.

+0

In welchem ​​Fall ist es möglich? – xport

+0

@xport - Ich habe ein Beispiel gegeben. In jedem Fall können Sie selbst eine Ausnahmeklasse schreiben und darin eine Ausnahme "werfen". Ausnahmen sind einfach Klassen und befolgen alle Klassenregeln. – Oded

2

Ja - sicherlich ist es möglich, dass eine Ausnahme selbst eine Ausnahme auslöst.

Die meisten (nicht alle) der Framework-Ausnahmen sind ziemlich leichte Dinge mit sehr wenig interner Logik, so dass die durchschnittliche Ausnahme wahrscheinlich nicht viel Spielraum hat, um Ausnahmen selbst zu generieren.

Ist dies eine Framework-Ausnahme, mit der Sie dieses Verhalten sehen? Kannst du uns ein paar Details geben?

Ein kurzer Blick auf die Interna der Ausnahme mit einem Tool wie Reflector kann Ihnen helfen, herauszufinden, was, wenn überhaupt, vor sich geht.

1

Ja. Das ist möglich.

Aber ich frage mich, warum man das jemals tun möchte? Ausnahmen sind nur für die Kommunikation von Fehlern so praktisch von Entwurf, sie können keinen ernsthaften Code oder Logik haben, die in ihnen laufen, die eine Ausnahme verursachen können. Wenn Sie Argument sind, möchten Sie möglicherweise die Ausnahme in Datenbank oder Festplatte protokollieren, die unter bestimmten Bedingungen eine Ausnahme verursachen könnte, dann würde ich nicht einmal zustimmen, da die Ausnahme im catch Block protokolliert werden sollte.

2

Ja, es ist möglich, obwohl nicht sehr typisch. Wenn die ausgelöste Ausnahme einen Fehler im Konstruktor hat oder von fehlenden Klassen abhängt, löst sie selbst eine Ausnahme aus.

Es ist einfach, dies zu testen: Erstellen Sie Ihre eigene Ausnahme, die versucht, eine Methode als NULL-Verweis aufzurufen. Wenn Sie die Ausnahme instanziieren, wird eine NullReferenceException ausgelöst.

1

Wenn Sie denken, dass das Ausnahmeobjekt versuchen sollte, die Situation zu behandeln und eine andere Ausnahme zu werfen, wenn es nicht möglich war, dass Sie falsch sind.
Der catch-Block sollte die falsche Situation behandeln und die Ausnahme weiter wegwerfen, wenn dies nicht möglich ist.
Beispiel:

try 
{ 
    BigResource r = new BigResource(); 
} 
catch(BigResourceException e) 
{ 
    bool cannotHandle = false; 
    // Handle exception here 

    if (cannotHandle) 
     throw e; 
} 
Verwandte Themen