UnhandledExceptions in einer Klassenbibliothek

VaporiZed schrieb:

Sobald das Hauptprogramm Deine DLL in einem Try-Block ausführt (wohl sehr wahrscheinlich, um das Fortführen des Hauptprogramms nicht zu gefährden), ist ja die DLL-Exception behandelt.

Das wird wohl so sein und erklärt warum alle meine Versuche das UnhandledException-Event auszulösen innerhalb einer DLL erfolglos blieben.

RodFromGermany schrieb:

Was genau stellst Du Dir unter Exception fangen und behandeln vor?

Zunächst möchte ich, dass die Excepion ein Event auslöst und mir somit alle Möglichkeiten gibt zu tun was ich möchte... In diesem konkreten Fall z.B. das Protokollieren der Exception.

ErfinderDesRades schrieb:

jaja, aber wie ich verstanden habe, ist das Fortfahren gar nicht das (nächste) Ziel des TE, sondern die Fehler ühaupt zu loggen und zu mailen, damit er als Entwickler überhaupt ein zeitnahes Feedback kriegt, wenn im Praxis-Einsatz was schief läuft.
Eine wirksame Fehlerbehandlung zu entwickeln wäre quasi erst das "Ziel nach dem Ziel"

So ist es...

Und mit Try/Catch kann ich natürlich die Exception fangen und entsprechend behandeln, bzw. protokollieren. Mein Problem ist es ja, dass ich noch gar nicht weis wo die Exception auftreten wird, denn wenn mir der Fehler bereits bekannt wäre, dann könnte ich Ihn ja schon zur Entwicklungszeit entsprechend vermeiden. Somit müsste ich ja quasi überall den gesamten Code in einem Try/Catch-Block einschließen, um alle eventuellen Exceptions zu fangen und zu protokollieren.
Aus diesem Grund auch der krampfhafte Versuch bei einer UnhandledException ein Event zu feuern, um somit global ohne Try/Catch die Exception zu fangen und zu protokollieren.

Aktuell habe ich einfach um den Formular-Aufruf ein Try/Catch gepackt, um somit die Exceptions die das Formular erzeugt abfangen zu können und zu protokollieren.
Der Endanwender bekommt dann noch eine freundliche MessageBox, in der er darauf hingewiesen wird das eine Exception aufgetreten ist und deswegen sein Formular beendet wurde.

RodFromGermany schrieb:

Wenn Du um die Zeile ein Try-Catch baust, ist das das, was Du willst.
Dies kannst Du auch in VB.NET so machen, dazu musst Du aber das Projekt entsprechend modifizieren.

​Ok, das verstehe ich... Dies entspricht ja in etwa dem was ich getan habe, indem ich um alle meine Aufrufe der Formulare ein Try/Catch gebaut habe. Natürlich ist um den Code, welcher sich außerhalb meiner Formular befindet kein Try/Catch.
​Dies ist aber nicht so schlimm für meinen Anwendungsfall, da außerhalb der Formulare der Code eher unkritisch ist und sich alle wirklich kritischen Abläufe innerhalb der Formulare abspielen.

RodFromGermany schrieb:

Glaube ich nicht ganz.
Hier brauchst Du nur ein einziges Try-Catch.

Hmm... Aber doch auch nur so lange, wie jede weitere Form über die Form1 aufgerufen, bzw. durch diese instanziert wird.
Denn der Try/Catch Block umfasst ja auch hier nur Form1. Wenn ich aus Form1 ausbreche und dann eine Exception auftritt, wird diese doch auch nicht mehr gefangen oder sehe ich das falsch?
Kenne mich leider, wie du bereits richtig festgestellt hast, überhaupt nicht mit C# aus.

Aber mal ein völlig abstrakter Gedankengang:

Mir fällt spontan nichts ein, warum es zwei solche Szenarien geben sollte, die dazu führen das beim Anwendungsstart zwischen zwei unterschiedlichen Start-Forms unterschieden werden sollte.
Aber hier würde ich doch theoretisch auch zwei Try/Catch benötigen oder?

Vielleicht denke ich aber auch nur viel zu abstrakt...

Aber so ähnlich verhält es sich ja mit meiner DLL, da diese ja nur ein AddIn darstellt. Denn primär läuft ja die eigentliche Software Autodesk Inventor und erst wenn ich eine der Schaltflächen im Ribbon klicke wird ein Form meines AddIns aufgerufen. So lange keine Schaltfläche geklickt wird, schläft meine DLL quasi im Hintergrund.

Bitte korrigiere mich, wenn ich hier einen völligen Gedankenfehler habe.
Ich bin immer gerne bereit mein Wissen zu erweitern.