Hi!
Vielen Dank, fuer Deine eMail! Das ist genau das was mir vorschwebt.
Die eigentlichen Codes fuer einen Eintrag im EventLog, eMail versandt,
DialogBoxen sind bereits vorhanden. Dennoch vielen Dank, fuer Deine
Beispiele. Was mir jetzt noch fehlt, ist, wie kann ich aus einer
Exception-Instanz herausfinden, ob die Exception von einer Windows
oder einer Webapplication heraus aufgerufen wurde?
Also:
Web- und WinForms:
try
{
int i = 1 / 0; // Geht eigentlich nicht, da der Compiler
// hier schon meckert
}
catch(Exception ec)
{
ErrorHandling.Error(ec);
}
Business Logic(Assembly):
class ErrorHandling
{
ErrorHandling()
{
}
public static void Error(Exception ec)
{
if (ec??? == Web???)
{
}
else if (ec??? == WinForms???)
{
}
}
}
Ich hab den Code mal eben aufgeschrieben, so wie ich es mir ungefaehr
denke.
Wie kann ich das realisieren?
Mit freundlichen Gruessen!
Kristian Tingler
bcs-Consult GmbH
www.iss3.de
-----Urspr�ngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Auftrag von Joachim van de Bruck
Gesendet: Sonntag, 19. Oktober 2003 17:17
An: [EMAIL PROTECTED]
Betreff: AW: [Asp.net] Web oder Windows Application?
Hallo!
So eine Klasse hatte ich auch mal im Einsatz. Eine kleine Assembly, die man
�berall einsetzen konnte, die eine E-Mail an den Entwickler und/oder einen
Eintrag ins EventLog und/oder eine MessageBox f�r den Anwender erzeugt.
Wahrscheinlich genau das, was Dir so verschwebt, oder?
Das kleine Problem ist, dass w�hrend der Ausf�hrung dieser Assembly wiederum
Exceptions entsstehen k�nnen, und das gr��ere Problem ist, dass beim Laden
der Assembly eine Exception erzeugt wird. Also braucht man trotz
ExceptionHandling-Assembly immer auch ein ExceptionHandling im eigentlichen
Programm.
Ich habe mich in der vorletzten Woche schon zu dem Thema ge�u�ert. Die
Quintessenz ist, dass ich jetzt mein "globales ExceptionHandling" im
Source-Code mache und mir ein paar zentrale Exception-Routinen aus dem VSS
in jedes Projekt (Web oder WindowsForms) einbinde.
z. B. Eintrag ins EventLog:
Sub ExceptionsWriteToEventLog(ByVal ex As Exception)
Try
Dim message as String = ex.Message & Environment.NewLine &
ex.StackTrace
Dim source as String =
Diagnostics.Process.GetCurrentProcess.ProcessName
If Not Diagnostics.EventLog.SourceExists(source) Then
Diagnostics.EventLog.CreateEventSource(source, "Application")
Dim log As New Diagnostics.EventLog
log.Log = "Application"
log.Source = "domain.tld"
log.WriteEntry(message)
Catch : End Try
End Sub
Oder E-Mail an Entwickler:
Sub ExceptionsMailToDeveloper(ByVal ex As Exception)
Try
Dim message as String = ex.Message & Environment.NewLine &
ex.StackTrace
Dim source as String =
Diagnostics.Process.GetCurrentProcess.ProcessName
Web.Mail.SmtpMail.Send( _
(Environment.UserName & "_" & Environment.MachineName & "@" &
Environment.UserDomainName).Replace(" ", ""), _
"[EMAIL PROTECTED]", _
"Fehler in " & source, _
message)
Catch : End Try
End Sub
In einer Web-Applikation kann man das dann innerhalb von
Application_Error(...) der Global.asax einsetzen:
Dim ex as Exception = Me.Server.GetLastError()
If Me.Server.MachineName().StartsWith("VDB") Then
Throw ex
Else
Try
Call ExceptionsMailToDeveloper(ex)
Catch
Call ExceptionsWriteToEventLog(ex)
End Try
End If
Eine WindowsForms-Applikation wird bei mir nie �ber die Form-Klasse sondern
immer �ber Sub Main() gestartet, auch wegen der XP-Styles,
Single-Instance-Test, Splash-Form, ...
Shared Sub Main()
Try
' single instance
If
Diagnostics.Process.GetProcessesByName(Diagnostics.Process.GetCurrentProcess
.ProcessName).Length > 1 Then
MessageBox.Show("Das Programm l�uft bereits auf diesem Rechner")
Application.ExitThread()
End If
' XP-Styles
Application.EnableVisualStyles()
' SplashForm, externe Assemblies und FormMain starten
Dim splash As New jvdb.Splasher
splash.Show()
Application.Run(New FormMain)
Catch ex As Exception
#If DEBUG = True Then
Throw ex
#Else
MessageBox.Show("Eine Situation ist eingetreten, die vom Programm
(noch) nicht nehandelt wird. Der Vorgang ist protokolliert. Versuchen Sie es
noch einmal oder wenden Sie sich an den HelpDesk.")
Call ExceptionsMailToDeveloper(ex)
Call ExceptionsWriteToEventLog(ex)
#End If
Finally
Application.ExitThread()
End Try
End Sub
Ansonsten gilt es, den Code mit If-Then-Else o.�. lokal abzusichern, oder
Alternativen mit Try-Catch-Finally einzubauen oder mitunter auch Exceptions
einfach zu ignorieren Try-Catch-EndTry. Ganz wichtig ist meines Erachtens,
dass die Exceptions f�r den Entwickler auch ankommen. Ein Try-Catch-Finally
vorsorglich in jedem einzelnen Modul verhindert das eher.
Freundliche Gr��e
Joachim van de Bruck
_______________________________________________
Asp.net mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/asp.net
Virengepr�ft vom G DATA AntiVirenKit
_______________________________________________
Asp.net mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/asp.net
