Re: Kein PaintWithErrorHandling
- From: "Armin Zingler" <az.nospam@xxxxxxxxxx>
- Date: Fri, 3 Jun 2005 09:22:15 +0200
"Maximilian Hänel" <ngSpam@xxxxxxx> schrieb
Das einzige, was PaintWithErrorHandling macht, ist im Falle einer unbehandelten Ausnahme ein Flag zu setzten, so dass beim nächsten OnPaint ein rotes Kreuz auf weißem Hintergrund gemalt wird. Anschließend wird die Ausnahme _unverändert weitergeworfen_.
Ja, unverändert, aber eben nicht an der Original Position.
Doch, das wirst du alleine schon anhand des StackTrace sehen.
Das ist es ja: Den muß ich erst suchen (s.u.). Ohne diese "Fehlerbehandlung" fiele das weg.
Und dieses unveränderte Weiterwerfen ist ja gerade der Witz an einem "rethrow". Etwas gänzlich anderes wäre ein "throw ex;", was übrigens _nicht_ mit einem Weiterwerfen zu verwechslen ist. Bei letztgenannten verlierst du tatsächlich die ursprüngliche Position inkl. StackTrace. Das würde dann auch unter Fehlerbehandlung laufen, da die catch Anweisung den ursprünglichen Fehler "schluckt". Dass kurz darauf erneut eine Ausnahme geworfen wird, sollte nicht darüber hinwegtäuschen.
Entschuldige mal, wenn die IDE nicht wie üblich in der Fehlerzeile stehen bleibt, dann muss doch irgendwas passiert sein. Ich nenne es Fehlerbehandlung. Sieh dir doch einfach mal den IL Code an. Es hat niemand behauptet, dass die Infos über die ursprüngliche Position verloren gehen. Es ist aber schwerer an sie ranzukommen. Versuche es einfach mal in der Praxis. Gerade noch einmal getestet: Exception in OnPaint geworfen => Run => IDE bleibt im Source-Code bei application.run stehen bzw. im Callstack etwas genauer bei Paintwitherrorhandling. Woher weiß ich jetzt die tatsächliche Position? Ich muss zum Callstack, dann ins Lokalfenter und dort die lokale Variable $exception untersuchen. Das war mein Stein des Anstoßes: Es muß erst so vorgegangen werden oder die ThreadException abgefangen werden. Was macht jemand, der mit dem "nicht-benutzerseitigen Code" nichts anfangen kann? Der steht verwundert auf application.run, der angeblichen Fehlerzeile, und versteht die Welt nicht mehr, weil dort einfach kein Fehler zu finden ist. Würde nicht passieren, wenn der Debugger, wie bei jeder anderen Exception auch, einfach 10 Zeilen darunter stehen bleiben würde, nämlich im Source-Code, der die Exception verursacht hat.
Gesetzt dem Fall die Position würde, wie du es schreibst, beim Weiterwerfen verändert, was wäre dann deiner Meinung nach der Unterschied zwischen diesem:
try { } catch(Exception ex) { throw ex; // _neue_ Ausnahme mit selben ex }
und diesem Code:
try { } catch(Exception) { throw; // rethrow }
Du musst mir die Unterschiede nicht erklären. Ich kann auch die
Threadexception handlen. Ich kann auch in OnPaint die Fehlerbehandlung
machen. Ich kann auch die Fehlerbehandungs-Optionen in der IDE selber
setzen. Alles kein Problem. Mir geht es einzig und allein im die Frage, *warum* *genau* *hier* eine ungewünschte Fehlerbehandlung stattfindet.
Der Grund für dieses Verhalten ist einfach: Eine unbehandelte Ausnahme, die während der Abarbeitung einer Windows Nachricht auftritt, landet in Application.ThreadException. Läuft das Programm unter einem Debugger, wird ein Dialogfeld angezeigt, in dem du wählen kannst, wie mit dem Programm im Weiteren vorgegangen werden soll.
Wenn du das nervige, sich nicht abstellen lassende "...Jitdebugging=True"-Dialogfeld meinst, dann kann ich darauf gerne verzichten und das Problem würde sich gar nicht stellen.
Es gibt genügend andere Methoden, die ein "try catch throw;" einsetzen (bzw. sogar müssen -> etwa Transaction Rollback). Dieses "Problem" ist somit nicht auf PaintWithErrorHandling und das Debug Dialogfeld zu reduzieren.
?? Dein Argument für die Existenberechtigung der "Fehlerbehandlung" (darf ich es so nennen?) im Paint war doch, dass der JitDebugging-Dialog sonst zu Rekursionen führen würde, weil bei jedem Bestätigen wieder ein Referesh stattfinden würde. Natürlich gibt es Einsatzmöglichkeiten für "try catch throw", aber das hat auch niemand bezweifelt. Die Frage ist, warum es gerade an dieser Stelle eingesetzt wird.
Handelt es sich bei dieser Ausnahme um eine unbehandelte Ausnahme, die in OnPaint geworfen wurde, so wird diese Ausnamhme spätestens beim Schließen des Ausnahmedialogfelds erneut geworfen, was wiederum das Ausnahmedialogfeld zum Vorschein bringt. Das Spielchen geht dann auf ewig so weiter. Um das zu verhindern, setzt PaintWithErrorHandling ein Flag, und verhindert so diese mehr als nervtötende Rekursion.
Dass das so funktioniert, ist mir klar. Wenn die Exception einfach nicht "gecatcht" würde, könnte man sich das ganze wohl sparen. Ich sehe jedenfalls keinen Unterschied zu anderen Exceptions. Wo ist denn das Problem, wenn die Exception nicht gefangen wird - mal abgesehen vom o.e. Dialogfeld?
Wo liegt denn aber das Problem, den Debugger so einzustellen, dass er dort stehen bleibt, wo die Ausnahme geworfen wurde? Das sind zwei, drei Mausklicks - das ist doch wirklich nicht der Diskussion wert, oder?
Wo ist die Begründung dafür, das machen zu müssen? Danach suche ich.
Wie stellst du dir das außerdem vor? In OnPaint einen Breakpoint setzen, die Einstellungen ändern - es könnte ja ein Fehler auftreten - und am Ende von OnPaint wieder die Einstellungen zurücknehmen und das Programm weiterlaufen lassen? Will damit sagen: Diese Einstellungen nützen mir für diesen Fall überhaupt nichts, denn sie gelten bekanntlich nicht nur für OnPaint. Daher weiß ich nicht, was du mit diesem Vorschlag bezweckst.
Andererseits: Wieviele Probleme wären zu erwarten, wenn man ein "try catch throw;" "verbieten" würde, nur weil der Debugger per Default sonst nicht dort stehen bleibt, wo es dir beliebt? Selbst wenn es kein PaintWithErrorHandling gäbe, würdest du früher oder später auf das selbe Problem an einer anderen Stelle treffen.
Wie gesagt, von einem generellen Verbieten von "try catch throw" ist nicht die Rede, sondern nur vom Grund für den Einsatz an genau dieser Stelle (also beim Paint).
Letztlich liegt dein geschildertes Problem eben nicht in PaintWithErrorHandling - wenn schon, dann müsstest du die Schuld beim Debugger suchen...
Ich sage es noch einmal: Es geht doch überhaupt nicht darum, ob ich irgendwelche Optionen setzen oder den Fehler selbst abfangen kann. Ich versuche herauszufinden, welche Beweggründe es für die Entwickler des Frameworks für die Differenzierung beim Auftreten von Exceptions an unterschiedlichen Positionen (Paint/Click) gibt. Du hast mir ehrlich gesagt auch noch kein schlüssiges Argument nennen können.
Armin
.
- Follow-Ups:
- Re: Kein PaintWithErrorHandling
- From: Maximilian Hänel
- Re: Kein PaintWithErrorHandling
- References:
- Re: Kein PaintWithErrorHandling
- From: Armin Zingler
- Re: Kein PaintWithErrorHandling
- From: Maximilian Hänel
- Re: Kein PaintWithErrorHandling
- From: Armin Zingler
- Re: Kein PaintWithErrorHandling
- From: Maximilian Hänel
- Re: Kein PaintWithErrorHandling
- Prev by Date: Installation und danach ein Update
- Next by Date: Re: Form unsichtbar aufbauen
- Previous by thread: Re: Kein PaintWithErrorHandling
- Next by thread: Re: Kein PaintWithErrorHandling
- Index(es):
Relevant Pages
|
