Exception weiterwerfen -> Stack weg!

[stimpleton]

Hallo,

ich mache in meiner dreischichtigen Anwendung folgendes:

- unterste Schicht wirft Exception (sehr spezielle Infos)
- mittlere Schicht packt diese in eine allgemeinere Exception
- wirft sie weiter an die Anwendung
- Anwendung behandelt die Exception

Das habe ich bei den Java-Leuten gesehen und fand es ganz gut.
Man kann immer weiter in die umhüllte Exception reinsteigen um mehr
Details zu erfahren. (z.B. "Senden ging nicht" -> "Protokollfehler")

Blöderweise ist nach dem Weiterwerfen einer Exception (d.h. catch
löst ein throw an die höhere Schicht aus) der Stack im Eimer. Warum???
Bei einfachem throw-catch ist er doch auch OK.

Das könnte beim Debuggen stören. Was haltet Ihr generell von dem
Weiterwerfen?

Danke,
Stimpy

[Konrad Rudolph]

stimpleton schrieb:

Blöderweise ist nach dem Weiterwerfen einer Exception (d.h. catch
löst ein throw an die höhere Schicht aus) der Stack im Eimer.

Bei welchem Compiler/mit welchem Code?

[stimpleton]

Mittelschicht (mittelschichts_funktion()):

try
{
   unterschichts_funktion(); 
}
catch( UnterschichtsException &e )
{
   throw MittelschichtException( e );
}

Oberschicht:

try 
{
   mittelschichts_funktion();
}
catch( MittelschichtException &e  )
{
   printf( "Hossa!" );
}

...ich hoffe mal, mir ist beim Vereinfachen kein Fehler unterlaufen.
Bei der Ausgabe von "Hossa" kann ich den Call Stack nicht mehr zurückverfolgen.
Das ganze mache ich mit Visual Studio .NET 2003.

Gruß,
Stimpy

[hustbaer]

Natürlich kannst du den Callstack nichtmehr zurückverfolgen, der ist bereits weg in dem Moment wo "catch passiert". Das heisst aber nicht dass irgendetwas "faul" wäre.
Du musst den Debugger einfach nur umstellen, dass er bereits beim "throw" unterbricht -- im MSVC geht das sehr schön, da kannste eigene Typen eintragen, und für jeden Typ angeben ob er bei "throw" unterbrechen soll.
Standardmässig unterbricht er halt nur wenn das Teil keiner fängt.

[stimpleton]

Danke!

Das ist mir neu, daß man auch beim throw unterbrechen lassen kann.
Damit kann man doch wieder brauchbar debuggen und meine Lösung verursacht
keine zusätzlichen Probleme. Klingt gut...