Exceptions automatisch abfangen
Hallo,
ich such eine (leichte & schnelle) Lösung für mein Problem.
Ich benutze eine recht große (fremd)-Bibliothek, welche jede Menge Exceptions wirft, z.B. wenn die Logindaten falsch waren.
Natürlich möchte ich bei solch einem kleinem Problem, wie z.B. falsche Logindaten, nicht, dass mein Programm abbricht, sondern dem User die Möglichkeit geben, darauf zu reagieren.
Ein weiteres Problem ist, dass eigentlich jede Funktion der Bilbiothek solche Exceptions werfen kann (falsche Userdaten), z.B. wenn der Server den User automatisch ausgelogt hat (Timeout).
Diese Execptions sind vom gleichen Typ, abgeleitet von Exceptions.
Solche Ausnahmen sollen immer gleich behandelt werden, also es soll z.B. ein Dialog erscheinen, wo der User seine Login Daten wieder eingeben kann.
Jetzt möchte, sofern es möglich ist, nicht bei jedem Funktionsaufruf ein try-catch Block schreiben, der bestimmte Exceptions abfängt (z.B. falsche Userdaten), sondern dies irgendwie automatisieren, aber wie?
Bsp:
bibliothek.Funktion1();
//...
bibliothek.Funktion2();
Bei Funktion2 passiert nun ein Fehler, dort soll dann gleich (automatisch) das Error-Handling eintreten.
Sofern der Fehler bekannt ist, werden bestimmte Funktionen wie ein Dialog anzeigen aufgerufen. Ist er unbekannt, wird die Exception weitergereicht, das Programm bricht an der Stelle ab.
Allerdings wie realisiere ich das?
Die Bilbliothek möchte ich ungerne Umschreiben, auf Grund des Zeitaufwandes und der Wiederverwendtbarkeit.
Die Klassen abzuleiten, und bei jeder Methode eine Fehlerbehandlung einzubauen, wäre auch recht aufwendig.
Gibt es evt. eine relativ leichte Methode, so dass ich alle BibliothekExceptions (abgeleitet von Exceptions) an ein bestimmtes Objekt/Klasse delegieren kann, und diese dann entscheidet, ob abgebrochen wird oder ähnliches passiert?
Jede Funktion in einen try-catch Container zu setzen fände ich persönlich sehr unübersichtlicht, denn die Bibliothek ist mit das Herzstück der Anwendung (also müsste ich jeden 3. Aufruf oder so anpassen).
Vielleicht hat ja jmd. eine Idee dazu.
MFG
Hallo Qwald,
die einzige sinnvolle Möglichkeit, die ich sehe, ist für jede (wichtige) Bibliotheksfunktion einen Wrapper zu schreiben (und bei den anderen direkt try/catch zu benutzen).
herbivore
Hallo !
Application.ThreadException += new ThreadExceptionEventHandler(OnThreadException);
Das entweder in der Main-Methode oder im Form.Load() Deines Hauptformulars sollte reichen. Damit fängst Du alle Exceptions, egal wo sie innerhalb deiner Anwendung geworfen wurden auf und kannst sie dann im Handler des Events behandeln.
"It is not wise to be wise" - Sun Tzu
Hallo,
danke Lynix, das ist genau das was ich gehofft habe.
Werde es später gleich mal ausprobieren, und hoffen das alles soweit klappt. 👍
ThreadException ist für Exceptions, die bei ner Windows.Forms Anwendung im GUI Thread geworfen werden. Eigentlich für solche gedacht, die durch Bedienung entstehen und nicht im Code abgefangen werden können.
Außerdem kannst du über Events nicht verhindern, dass sich das Programm beendet wenn eine Exception nicht gecatcht wird. Um try&catch führt nichts herum, sinnvoll wäre wie Herbivore sagte ein Wrapper, um den Code mit try&catch nicht völlig unleserlich zu machen.
e.f.q.
Aus Falschem folgt Beliebiges
Hallo,
ok schade. Werde dann wohl einen Adapter für die Klasse schreiben müssen.
Nur zum loggen zu gebrauchen weil man auch hier die Exception nicht wirklich behandeln kann.
e.f.q.
Aus Falschem folgt Beliebiges
@Traumzauberbaum
ThreadException ist für Exceptions, die bei ner Windows.Forms Anwendung im GUI Thread geworfen werden.
Falsch, ThreadException fängt sämtliche Exceptions aus allen Threads innerhalb der Anwendung auf.
Außerdem kannst du über Events nicht verhindern, dass sich das Programm beendet wenn eine Exception nicht gecatcht wird. Um try&catch führt nichts herum, sinnvoll wäre wie Herbivore sagte ein Wrapper, um den Code mit try&catch nicht völlig unleserlich zu machen.
Stimmt, da hatte ich wohl das ursprüngliche Problem falsch verstanden. Diese Thread-Exception Methodik dient eigentlich nur dazu, überhaupt mitzukriegen, dass irgendwo eine Exception aufgetreten ist. Tritt eine Exception in einem selbst erstellten Thread auf, kriegt man nämlich, sofern man die Exception nicht mit try/catch auffängt, garnichts davon mit. Der Thread stirbt einfach und man wundert sich evtl. über komisches Verhalten der Anwendung.
Also wenn es darum geht, die Exception in der Art zu behandeln, dass die Anwendung anschliessend weiter laufen kann, ist ThreadException nicht besonders gut geeignet.
Andererseits sorgt eine Exception, die in einem eigenen Thread auftritt normalerweise nicht für einen Absturz der Anwendung. D.h. es gibt sicher Fälle, wo die Exception in einem Thread "nicht wichtig" für den weiteren Ablauf des Programmes ist. Im EventHandler könnte man daher evtl. schon ermitteln, welche Art von Exception es war und anhand der Info die man so erhält, entscheiden, ob man die Anwendung beenden muss oder nicht.
"It is not wise to be wise" - Sun Tzu
Original von Lynix
@TraumzauberbaumThreadException ist für Exceptions, die bei ner Windows.Forms Anwendung im GUI Thread geworfen werden.
Falsch, ThreadException fängt sämtliche Exceptions aus allen Threads innerhalb der Anwendung auf.
Das hast Du getestet, damit Du es mit Gewissheit behaupten kannst?
Denn ich denke Du liegst hier falsch.
Man sollte solche Events nur verwenden um den Nutzer zu informieren, dass die Anwendung in ihrer Stabilität gefährdet ist und ihn zum Speichern und Neustart auffordern. Die Anwendung einfach weiter laufen zu lassen, wäre gefährlich. Anders sieht das mit durch try/catch gefangenen Exceptions aus. Hier kann man durchaus wieder von einem konsistenten Zustand der Anwendung ausgehen (je nach Code). Insofern sollten diese Events nur ein Notanker sein und keinesfalls - wie gewollt - "vereinfachte" Methode der Ausnahmebehandlung. Das können diese Events nicht leisten.
Original von Lynix
Andererseits sorgt eine Exception, die in einem eigenen Thread auftritt normalerweise nicht für einen Absturz der Anwendung. D.h. es gibt sicher Fälle, wo die Exception in einem Thread "nicht wichtig" für den weiteren Ablauf des Programmes ist. Im EventHandler könnte man daher evtl. schon ermitteln, welche Art von Exception es war und anhand der Info die man so erhält, entscheiden, ob man die Anwendung beenden muss oder nicht.
In .NET 1.1 ist das durchaus noch so, aber in 2.0 führt fast jede Exception in einem beliebigen Thread in einer beliebigen AppDomain dazu, dass das Programm beendet wird. Ich glaube die Ausnahmen kann man an einer Hand abzählen, zum Beispiel die ThreadAbortException.
e.f.q.
Aus Falschem folgt Beliebiges