Autor Beitrag
mo#
Hält's aus hier
Beiträge: 2



BeitragVerfasst: Fr 20.08.10 14:28 
Hallo zusammen,

ich entwickle gerade an einem Windows-Service was Neuland für mich darstellt.
Nun habe ich ein Problem mit dem Exception Handling.
Meine Konzept war eigentlich Exceptions die ich abfangen kann direkt zu behandeln und die unbehandelten Fehler über das AppDomain.CurrentDomain.UnhandledException Event abzufangen, was jedoch in Win Services leider nicht möglich ist :-/

Nun wollte ich meine Methoden in try/catch Blöcke packen und die unbehandelten Fehler bis zum Konstruktor des Service durchreichen.
Dabei ergibt sich das Problem das ich die Mehtode und die Klasse meines eigenen Codes nicht rausbekomme in der die Exception stattfindet.
z.B. bekomme bei einer FileNotFound Exception als Exception.Source = WinIO und als TargetSite = .ctor.
Wenn ich nun aber in der Klasse in der der Fehler auftritt im Catch "throw ex;" verwende, kann ich die Variablen richtig auslesen, habe aber kein Stacktrace mehr..
Jemand ne Idee wie ich an beides mit Bordmitteln komme?
Und gibt es sowas wie eine Best Practice für das Exceptionhandling in Win-Services?

Vielen Dank.

Grüße
mo#
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Sa 21.08.10 10:22 
:welcome:

user profile iconmo# hat folgendes geschrieben Zum zitierten Posting springen:
Dabei ergibt sich das Problem das ich die Mehtode und die Klasse meines eigenen Codes nicht rausbekomme in der die Exception stattfindet.
Wofür brauchst du denn diese Informationen? Zum Loggen/"Post-Mortem Debugging" sollte doch der Stacktrace ausreichen. Ansonsten wirst du beim throw die Exception in einer eigenen Exception-Klasse wrappen müssen.

_________________
>λ=
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Sa 21.08.10 12:37 
Zitat:
Nun wollte ich meine Methoden in try/catch Blöcke packen und die unbehandelten Fehler bis zum Konstruktor des Service durchreichen.


Konstruktor? Was machst du da? Es ist eher ungewöhnlich irgendwas im Konstruktor des Services zu machen. Initialisierungen/Deinitialisierungen sollten eigentlich ins OnStart/OnStop Methodenpaar.

Zitat aus der Msdn zum ServiceBase Konstruktor
Zitat:
Erstellen Sie keine Instanz der ServiceBase-Klasse.Leiten Sie stattdessen von ServiceBase ab, und instanziieren Sie die abgeleitete Klasse.Bei einer von ServiceBase abgeleiteten Klasse muss als Mindestimplementierung der ServiceName für die Komponente im Konstruktor festgelegt sein.Dies ist die einzige Verarbeitung, die im Konstruktor speziell erforderlich ist.Den überwiegenden Teil der Initialisierung müssen Sie in OnStart anstatt im Konstruktor verarbeiten.Andernfalls ist nicht gewährleistet, dass beim Neustart eines beendeten Diensts die Objekte erneut initialisiert werden.
mo# Threadstarter
Hält's aus hier
Beiträge: 2



BeitragVerfasst: Mo 23.08.10 08:17 
user profile iconKha hat folgendes geschrieben Zum zitierten Posting springen:

user profile iconmo# hat folgendes geschrieben Zum zitierten Posting springen:
Dabei ergibt sich das Problem das ich die Mehtode und die Klasse meines eigenen Codes nicht rausbekomme in der die Exception stattfindet.
Wofür brauchst du denn diese Informationen? Zum Loggen/"Post-Mortem Debugging" sollte doch der Stacktrace ausreichen. Ansonsten wirst du beim throw die Exception in einer eigenen Exception-Klasse wrappen müssen.

Zum Ordentlichen Loggen, dabei will ich natürlich sehen was den Service in den Tod gerisses hat...


user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Zitat:
Nun wollte ich meine Methoden in try/catch Blöcke packen und die unbehandelten Fehler bis zum Konstruktor des Service durchreichen.


Konstruktor? Was machst du da? Es ist eher ungewöhnlich irgendwas im Konstruktor des Services zu machen. Initialisierungen/Deinitialisierungen sollten eigentlich ins OnStart/OnStop Methodenpaar.


Falsch ausgedrück, sorry ich war schon einen Schritt weiter. Der Service ruft eine DLL und im Konstruktor dieser will ich alle unhandled Exceptions abfangen, in der On Start-Methode werden sie automatisch gefangen aber da ist es schon zu spät ;-)
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Mo 23.08.10 17:55 
Und, was sagst du zu meinen Vorschlägen :nixweiss: ?

_________________
>λ=