Logging (exceptions etc)

[Einar Høst]

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullException (I'd have to subtype
it).

3) Use a decorator object to wrap the original object, catch all exceptions,
write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it isn't,
it ain't. That's logic" -- Lewis Carroll

[Saurabh Nandu]

Hi,

Have you looked at the Exception Mangement Application Block at MSDN ?

The Exception Management Application Block provides a simple yet extensible framework for handling exceptions. With a single line of application code you can easily log exception information to the Event Log or extend it by creating your own components that log exception details to other data sources or notify operators, without affecting your application code. The Exception Management Application Block can easily be used as a building block in your own .NET application.

[ http://msdn.microsoft.com/library/de...ml/emab-rm.asp ]
Regards,
Saurabh Nandu

[Einar Høst]

Hi,

Thanks for the tip. I actually did take a look at it a while ago, but at
that time I wasn't really into exception management the way I am now. I'll
take a fresh look at it, thanks.

Regards,
Einar

"Saurabh Nandu" <Sa**********@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...

Hi,

Have you looked at the Exception Mangement Application Block at MSDN ?

The Exception Management Application Block provides a simple yet extensible framework for handling exceptions. With a single line of
application code you can easily log exception information to the Event Log
or extend it by creating your own components that log exception details to
other data sources or notify operators, without affecting your application
code. The Exception Management Application Block can easily be used as a
building block in your own .NET application.
[ http://msdn.microsoft.com/library/de...ml/emab-rm.asp ]

Regards,
Saurabh Nandu

[David Levine]

As someone else wrote, start with the MS Exception Management block. You may
need to modify/extend it but it's a pretty good starting point.

I use a strategy that boils down to this...

If it's an exception that my own code throws then if it's the 1st time that
an exception has been thrown I log it. If it's being propagated up a call
stack (this happens when a catch block catches it, wraps it in another
exception, and rethrows it), I do not log it. I detect this in the
constructor of the exception object by examining the InnerException property
value.

If the exception is thrown by an external module then the catching code must
manually call the exception publish method if it is warranted.

If the exception is crossing a boundary I log it (perhaps again) - this
ensures that exception data is never lost in case the original site that
generated the exception did not log it. You must define what the boundary
is - it can be an appdomain, machine, server, module, etc.

Another thing to look for are cases where an exception gets swallowed. While
this is considered to be "bad" it nonetheless still happens, sometimes
legitimately. We require all such cases to call a method called
SwallowException. Currently it just outputs the exception message to the
trace buffer. I've identified a number of areas in our app where exceptions
were being swallowed that never should have been generated at all.

Server-side applications has more need to log exceptions then client-side
code since they do not have access to a UI to display fault information.
Applications can always make system-wide policy decisions about logging,
unhandled exception policy, etc.

Components (libraries) have a more difficult decision to make since they are
small pieces that do not "own" a logging policy or mechanism. They may not
even have security privileges sufficient to log to a file or create an
eventlog source. If you don't know the environment a component will be used
in you cannot make assumptions about what will be available at runtime. In
this case you should only throw the exception and let the code using the
component make the decision about how to handle the exception.

There currently is no system-wide notification that is generated whenever
any exception is thrown - this is unfortunate because this would be useful
for ensuring that exceptions are always logged.

"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullException (I'd have to subtype it).

3) Use a decorator object to wrap the original object, catch all exceptions, write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic" -- Lewis Carroll

[Einar Høst]

Thanks for your thoughts, definitely valuable input for developing my own
strategy!

Regards,
Einar

[Jay B. Harlow [MVP - Outlook]]

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullException (I'd have to subtype it).

3) Use a decorator object to wrap the original object, catch all exceptions, write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic" -- Lewis Carroll

[Einar Høst]

Hi Jay,

Thanks for the input and the pointer to the article. I think I may have read
it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring everything
else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eW**************@tk2msftngp13.phx.gbl...

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm raises an exception, the Application.ThreadException handler will catch all uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some much-needed logging across dlls in the project we're working on. However, being a newbie, I'm wondering if some more experienced loggers can provide me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for standard .NET exceptions such as ArgumentNullException (I'd have to

subtype

it).

3) Use a decorator object to wrap the original object, catch all

exceptions,

write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,

it ain't. That's logic" -- Lewis Carroll

[David Levine]

If you want to avoid bringing everything else down then you cannot allow the
exception to be unhandled, especially if you are writing an add-in. You
should wrap all threads that you create in try-catch blocks.

The rules under v1.0 and v1.1 of the runtime are that if the unhandled
exception occurs on the main thread or a thread that originates in unmanaged
code the application will be terminated. You cannot change this - it is
baked into the runtime.

If the unhandled exception occurs on a thread other then this, such as a
threadpool thread, one manually started, or the finalizer thread, then an
unhandled exception event will be sent and the exception will be swallowed.
While the current implementation of the runtime does not terminate an app on
these threads there is no guarantee that this will not change, and in fact
it probably will (and should) change.

There is a flag in the event args that indicates if the app will exit - this
is a readonly indicator of what will happen to the app after the UE handler
has run to completion.

I also disagree conceptually with using the UE handler as the backstop
exception handler. It is convenient to use it that way but I consider it to
be bad practice - I prefer to wrap all threads, etc. in a try-catch, also
using specific try-catches as necessary to locally recover from errors, and
I treat all UEs as a indication that a programming error may have occurred.
I definitely log all that I get but I consider them to be bugs.

I agree with the liberal use of try-finally blocks.

regards,
Dave
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

Hi Jay,

Thanks for the input and the pointer to the article. I think I may have read it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring everything else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eW**************@tk2msftngp13.phx.gbl...

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may

use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when

you

use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to

the

Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm

raises an exception, the Application.ThreadException handler will catch

all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide

some much-needed logging across dlls in the project we're working on. However, being a newbie, I'm wondering if some more experienced loggers can provide me with some ideas as to how to log in a simple yet flexible manner. For instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions. This makes the logging more transparent in the code, but doesn't work for standard .NET exceptions such as ArgumentNullException (I'd have to

subtype

it).

3) Use a decorator object to wrap the original object, catch all

exceptions,

write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,

it ain't. That's logic" -- Lewis Carroll

[Jay B. Harlow [MVP - Outlook]]

Einar,
As David suggests: For information & ideas on exception handling in Add-Ins
see:

http://msdn.microsoft.com/msdnmag/is...10/Plug%2Dins/

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

Hi Jay,

Thanks for the input and the pointer to the article. I think I may have read it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring everything else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eW**************@tk2msftngp13.phx.gbl...

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may

use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when

you

use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to

the

Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm

raises an exception, the Application.ThreadException handler will catch

all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide

some much-needed logging across dlls in the project we're working on. However, being a newbie, I'm wondering if some more experienced loggers can provide me with some ideas as to how to log in a simple yet flexible manner. For instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions. This makes the logging more transparent in the code, but doesn't work for standard .NET exceptions such as ArgumentNullException (I'd have to

subtype

it).

3) Use a decorator object to wrap the original object, catch all

exceptions,

write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,

it ain't. That's logic" -- Lewis Carroll

[Einar Høst]

Hi David,

Thanks for the input. I'm learning a lot from this.

I agree with your reasoning; however, since there are several developers on
my project, there is no way I can guarantee that the guidelines you're
outlining will actually be followed. I'm not even sure if I can trust myself
all the time. I'm trying to do things the right way, though.

So basically I'm thinking I need to include a UE handler as a last resort,
in order enable some logging that might point in the direction of the weak
code. The reason I'm looking into these things a bit more seriously is that
I've become annoyed with the add-in dying (and taking the main app with it)
with little or no information saying why.

Thanks again,
Einar.
"David Levine" <no****************@wi.rr.com> wrote in message
news:OW*************@TK2MSFTNGP11.phx.gbl...

If you want to avoid bringing everything else down then you cannot allow the exception to be unhandled, especially if you are writing an add-in. You
should wrap all threads that you create in try-catch blocks.

The rules under v1.0 and v1.1 of the runtime are that if the unhandled
exception occurs on the main thread or a thread that originates in unmanaged code the application will be terminated. You cannot change this - it is
baked into the runtime.

If the unhandled exception occurs on a thread other then this, such as a
threadpool thread, one manually started, or the finalizer thread, then an
unhandled exception event will be sent and the exception will be swallowed. While the current implementation of the runtime does not terminate an app on these threads there is no guarantee that this will not change, and in fact
it probably will (and should) change.

There is a flag in the event args that indicates if the app will exit - this is a readonly indicator of what will happen to the app after the UE handler has run to completion.

I also disagree conceptually with using the UE handler as the backstop
exception handler. It is convenient to use it that way but I consider it to be bad practice - I prefer to wrap all threads, etc. in a try-catch, also
using specific try-catches as necessary to locally recover from errors, and I treat all UEs as a indication that a programming error may have occurred. I definitely log all that I get but I consider them to be bugs.

I agree with the liberal use of try-finally blocks.

regards,
Dave
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

Hi Jay,

Thanks for the input and the pointer to the article. I think I may have

read

it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring

everything

else down with us... I think the rest of the guys I'm working with should

read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:eW**************@tk2msftngp13.phx.gbl...

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you

use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached

to

the

Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm

raises an exception, the Application.ThreadException handler will

catch all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...
> Hi,
>
> I'm getting into the Trace-functionality in .NET, using it to

provide some

> much-needed logging across dlls in the project we're working on.

However,

> being a newbie, I'm wondering if some more experienced loggers can

provide

> me with some ideas as to how to log in a simple yet flexible manner. For > instance, I'd like the code to be as uncluttered as possible by

Trace > statements.
>
> As an example of basic logging functionality, I've come up with some
> alternatives for logging exceptions that occur in an object:
>
> 1) Wrap the throwing of an exception in a method, which can handle any > logging before throwing the actual exception.
>
> 2) Handle logging in the constructors of my own hierarchy of

exceptions. > This makes the logging more transparent in the code, but doesn't work for

> standard .NET exceptions such as ArgumentNullException (I'd have to
subtype
> it).
>
> 3) Use a decorator object to wrap the original object, catch all
exceptions,
> write to log, and rethrow.
>
> Any and all thoughts/comments are much appreciated!
>
> Regards,
> Einar
>
> --
> "If it was so, it might be; and if it were so, it would be; but as

it isn't,
> it ain't. That's logic" -- Lewis Carroll
>
>

[Einar Høst]

Hi Jay,

Thanks for the reference, I'll do some reading this afternoon :-)

Regards,
Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Einar,
As David suggests: For information & ideas on exception handling in Add-Ins see:

http://msdn.microsoft.com/msdnmag/is...10/Plug%2Dins/

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

Hi Jay,

Thanks for the input and the pointer to the article. I think I may have

read

it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring

everything

else down with us... I think the rest of the guys I'm working with should

read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:eW**************@tk2msftngp13.phx.gbl...

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you

use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached

to

the

Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm

raises an exception, the Application.ThreadException handler will

catch all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...
> Hi,
>
> I'm getting into the Trace-functionality in .NET, using it to

provide some

> much-needed logging across dlls in the project we're working on.

However,

> being a newbie, I'm wondering if some more experienced loggers can

provide

> me with some ideas as to how to log in a simple yet flexible manner. For > instance, I'd like the code to be as uncluttered as possible by

Trace > statements.
>
> As an example of basic logging functionality, I've come up with some
> alternatives for logging exceptions that occur in an object:
>
> 1) Wrap the throwing of an exception in a method, which can handle any > logging before throwing the actual exception.
>
> 2) Handle logging in the constructors of my own hierarchy of

exceptions. > This makes the logging more transparent in the code, but doesn't work for

> standard .NET exceptions such as ArgumentNullException (I'd have to
subtype
> it).
>
> 3) Use a decorator object to wrap the original object, catch all
exceptions,
> write to log, and rethrow.
>
> Any and all thoughts/comments are much appreciated!
>
> Regards,
> Einar
>
> --
> "If it was so, it might be; and if it were so, it would be; but as

it isn't,
> it ain't. That's logic" -- Lewis Carroll
>
>

[Steel City Phantom]

how exactly do you do this on windows services? i am tracking a
filesystemwatcher problem that is looking more and more like a framework
bug, but i can only get very little detail and it kills my service. i
specified the AppDomain.UnhandledException handler in my service main
function, but its still not catching this error that keeps popping up.
Message by Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> on: 7/9/2004 10:58:48 AM

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullException (I'd have to

subtype

it).

3) Use a decorator object to wrap the original object, catch all

exceptions,

write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,

it ain't. That's logic" -- Lewis Carroll

[Dhominator]

You don't want app domain stuff usless your are creating app domains.
Just use Application.ThreadException... something like below... sample
class attached.

CustomExceptionHandler eh = new CustomExceptionHandler();
Application.ThreadException += new ThreadExceptionEventHandler(
eh.OnThreadException );

Best,
/jhd

p.s. timers, filesyswatchers are all different processes... need
semaphores vs monitor/lock

Steel City Phantom wrote:

how exactly do you do this on windows services? i am tracking a
filesystemwatcher problem that is looking more and more like a framework
bug, but i can only get very little detail and it kills my service. i
specified the AppDomain.UnhandledException handler in my service main
function, but its still not catching this error that keeps popping up.
Message by Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> on: 7/9/2004 10:58:48 AM

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullException (I'd have to

subtype

it).

3) Use a decorator object to wrap the original object, catch all

exceptions,

write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,

it ain't. That's logic" -- Lewis Carroll

/// <summary>
/// Top level exception handler. Future home of automatic bug report form and add to bug database.
/// </summary>
internal class CustomExceptionHandler
{
// Handles the exception event.
public void OnThreadException( object sender, ThreadExceptionEventArgs t )
{
DialogResult result = DialogResult.Cancel;
try
{
result = this.ShowThreadExceptionDialog( t.Exception );
}
catch
{
try
{
MessageBox.Show( "Fatal Error", "Fatal Error", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
finally
{
Application.Exit();
}
}

// Exits the program when the user clicks Abort.
if( result == DialogResult.Abort )
Application.Exit();
}

// Creates the error message and displays it.
private DialogResult ShowThreadExceptionDialog( Exception e )
{
string errorMsg = "An error occurred please contact the adminstrator with the following information:\n\n";
errorMsg = errorMsg + e.Message + "\n\nStack Trace:\n" + e.StackTrace;
return MessageBox.Show( errorMsg, "Application Error", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
}

[Dhominator]

clarification... System.Windows.Forms.Application.ThreadException.. . per
Jay's reply. I don't think it's winform specific... just where it lives.

/jhd

Dhominator wrote:

You don't want app domain stuff usless your are creating app domains.
Just use Application.ThreadException... something like below... sample
class attached.

CustomExceptionHandler eh = new CustomExceptionHandler();
Application.ThreadException += new ThreadExceptionEventHandler(
eh.OnThreadException );

Best,
/jhd

p.s. timers, filesyswatchers are all different processes... need
semaphores vs monitor/lock

Steel City Phantom wrote:

how exactly do you do this on windows services? i am tracking a
filesystemwatcher problem that is looking more and more like a framework
bug, but i can only get very little detail and it kills my service. i
specified the AppDomain.UnhandledException handler in my service main
function, but its still not catching this error that keeps popping up.
Message by Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> on:
7/9/2004 10:58:48 AM

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read
I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your
app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why &
when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached
to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the
MainForm
raises an exception, the Application.ThreadException handler will
catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

Hi,

I'm getting into the Trace-functionality in .NET, using it to
provide some
much-needed logging across dlls in the project we're working on.
However,
being a newbie, I'm wondering if some more experienced loggers can
provide
me with some ideas as to how to log in a simple yet flexible manner.
For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of
exceptions.
This makes the logging more transparent in the code, but doesn't
work for
standard .NET exceptions such as ArgumentNullException (I'd have to
subtype

it).

3) Use a decorator object to wrap the original object, catch all
exceptions,

write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it
isn't,

it ain't. That's logic" -- Lewis Carroll

------------------------------------------------------------------------

/// <summary>
/// Top level exception handler. Future home of automatic bug report form and add to bug database.
/// </summary>
internal class CustomExceptionHandler
{
// Handles the exception event.
public void OnThreadException( object sender, ThreadExceptionEventArgs t )
{
DialogResult result = DialogResult.Cancel;
try
{
result = this.ShowThreadExceptionDialog( t.Exception );
}
catch
{
try
{
MessageBox.Show( "Fatal Error", "Fatal Error", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
finally
{
Application.Exit();
}
}

// Exits the program when the user clicks Abort.
if( result == DialogResult.Abort )
Application.Exit();
}

// Creates the error message and displays it.
private DialogResult ShowThreadExceptionDialog( Exception e )
{
string errorMsg = "An error occurred please contact the adminstrator with the following information:\n\n";
errorMsg = errorMsg + e.Message + "\n\nStack Trace:\n" + e.StackTrace;
return MessageBox.Show( errorMsg, "Application Error", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
}

[Justin Rogers]

I'd be careful thinking that way. OnThreadException is based around a message
loop
and the exception being raised is from within a call-stack where the message
loop is
somewhere lower. In some cases I believe there may be more hook-up going on,
but not quite sure.

Maybe you should check out AppDomain.UnhandledException
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Dhominator" <a@b.c> wrote in message
news:%2*****************@TK2MSFTNGP12.phx.gbl...

clarification... System.Windows.Forms.Application.ThreadException.. . per Jay's
reply. I don't think it's winform specific... just where it lives.

/jhd

Dhominator wrote:

You don't want app domain stuff usless your are creating app domains. Just
use Application.ThreadException... something like below... sample class
attached.

CustomExceptionHandler eh = new CustomExceptionHandler();
Application.ThreadException += new ThreadExceptionEventHandler(
eh.OnThreadException );

Best,
/jhd

p.s. timers, filesyswatchers are all different processes... need semaphores
vs monitor/lock

Steel City Phantom wrote:

how exactly do you do this on windows services? i am tracking a
filesystemwatcher problem that is looking more and more like a framework
bug, but i can only get very little detail and it kills my service. i
specified the AppDomain.UnhandledException handler in my service main
function, but its still not catching this error that keeps popping up.
Message by Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> on:
7/9/2004 10:58:48 AM

Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when
you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to
the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the
MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotmail.com> wrote in message
news:uw**************@tk2msftngp13.phx.gbl...

> Hi,
>
> I'm getting into the Trace-functionality in .NET, using it to provide some
> much-needed logging across dlls in the project we're working on. However,
> being a newbie, I'm wondering if some more experienced loggers can provide
> me with some ideas as to how to log in a simple yet flexible manner. For
> instance, I'd like the code to be as uncluttered as possible by Trace
> statements.
>
> As an example of basic logging functionality, I've come up with some
> alternatives for logging exceptions that occur in an object:
>
> 1) Wrap the throwing of an exception in a method, which can handle any
> logging before throwing the actual exception.
>
> 2) Handle logging in the constructors of my own hierarchy of exceptions.
> This makes the logging more transparent in the code, but doesn't work for
> standard .NET exceptions such as ArgumentNullException (I'd have to
subtype

> it).
>
> 3) Use a decorator object to wrap the original object, catch all
exceptions,

> write to log, and rethrow.
>
> Any and all thoughts/comments are much appreciated!
>
> Regards,
> Einar
>
> --
> "If it was so, it might be; and if it were so, it would be; but as it
isn't,

> it ain't. That's logic" -- Lewis Carroll
>
>

------------------------------------------------------------------------

/// <summary>
/// Top level exception handler. Future home of automatic bug report form and
add to bug database.
/// </summary>
internal class CustomExceptionHandler
{
// Handles the exception event.
public void OnThreadException( object sender, ThreadExceptionEventArgs t )
{
DialogResult result = DialogResult.Cancel;
try
{
result = this.ShowThreadExceptionDialog( t.Exception );
}
catch
{
try
{
MessageBox.Show( "Fatal Error", "Fatal Error",
MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
finally
{
Application.Exit();
}
}

// Exits the program when the user clicks Abort.
if( result == DialogResult.Abort )
Application.Exit();
}

// Creates the error message and displays it.
private DialogResult ShowThreadExceptionDialog( Exception e )
{
string errorMsg = "An error occurred please contact the adminstrator with the
following information:\n\n";
errorMsg = errorMsg + e.Message + "\n\nStack Trace:\n" + e.StackTrace;
return MessageBox.Show( errorMsg, "Application Error",
MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
}

[Steel City Phantom]

your right, but the appdomain doesn't catch it and the application puts
it in an infinate loop.

now what.

Message by Justin Rogers <Ju****@games4dotnet.com> on: 11/4/2004 4:21:21 PM

I'd be careful thinking that way. OnThreadException is based around a message
loop
and the exception being raised is from within a call-stack where the message
loop is
somewhere lower. In some cases I believe there may be more hook-up going on,
but not quite sure.

Maybe you should check out AppDomain.UnhandledException
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Dhominator" <a@b.c> wrote in message
news:%2*****************@TK2MSFTNGP12.phx.gbl.. .

clarification... System.Windows.Forms.Application.ThreadException.. . per Jay's
reply. I don't think it's winform specific... just where it lives.

/jhd

Dhominator wrote:

You don't want app domain stuff usless your are creating app domains. Just
use Application.ThreadException... something like below... sample class
attached.

CustomExceptionHandler eh = new CustomExceptionHandler();
Application.ThreadException += new ThreadExceptionEventHandler(
eh.OnThreadException );

Best,
/jhd

p.s. timers, filesyswatchers are all different processes... need semaphores
vs monitor/lock

Steel City Phantom wrote:

how exactly do you do this on windows services? i am tracking a
filesystemwatcher problem that is looking more and more like a framework
bug, but i can only get very little detail and it kills my service. i
specified the AppDomain.UnhandledException handler in my service main
function, but its still not catching this error that keeps popping up.
Message by Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> on:
7/9/2004 10:58:48 AM

> Einar,
> In addition to the other comments about using the Exception Management
> Block, I normally do my logging in a global exception handler. (Read I may
> use the Exception Management Block in my Global Exception Handler)
>
> Also I use try/finally & using more then I use try/catch. I only use
> try/catch when there is something specific that I need to do with the
> exception, otherwise I let my global exception handlers handle the
> exception.
>
> Depending on the type of application you are creating, .NET has three
> different global exception handlers.
>
> For ASP.NET look at:
> System.Web.HttpApplication.Error event
> Normally placed in your Global.asax file.
>
> For console applications look at:
> System.AppDomain.UnhandledException event
> Use AddHandler in your Sub Main.
>
> For Windows Forms look at:
> System.Windows.Forms.Application.ThreadException event
> Use AddHandler in your Sub Main.
>
> It can be beneficial to combine the above global handlers in your app, as
> well as wrap your Sub Main in a try catch itself.
>
> There is an article in the June 2004 MSDN Magazine that shows how to
> implement the global exception handling in .NET that explains why & when
> you
> use multiple of the above handlers...
>
> http://msdn.microsoft.com/msdnmag/is...T/default.aspx
>
> For example: In my Windows Forms apps I would have a handler attached to
> the
> Application.ThreadException event, plus a Try/Catch in my Main. The
> Try/Catch in Main only catches exceptions if the constructor of the
> MainForm
> raises an exception, the Application.ThreadException handler will catch all
> uncaught exceptions from any form/control event handlers.
>
> Hope this helps
> Jay
>
>
> "Einar Høst" <_e*******@hotmail.com> wrote in message
> news:uw**************@tk2msftngp13.phx.gbl...
>
>> Hi,
>>
>> I'm getting into the Trace-functionality in .NET, using it to provide some
>> much-needed logging across dlls in the project we're working on. However,
>> being a newbie, I'm wondering if some more experienced loggers can provide
>> me with some ideas as to how to log in a simple yet flexible manner. For
>> instance, I'd like the code to be as uncluttered as possible by Trace
>> statements.
>>
>> As an example of basic logging functionality, I've come up with some
>> alternatives for logging exceptions that occur in an object:
>>
>> 1) Wrap the throwing of an exception in a method, which can handle any
>> logging before throwing the actual exception.
>>
>> 2) Handle logging in the constructors of my own hierarchy of exceptions.
>> This makes the logging more transparent in the code, but doesn't work for
>> standard .NET exceptions such as ArgumentNullException (I'd have to
>
>
> subtype
>
>> it).
>>
>> 3) Use a decorator object to wrap the original object, catch all
>
>
> exceptions,
>
>> write to log, and rethrow.
>>
>> Any and all thoughts/comments are much appreciated!
>>
>> Regards,
>> Einar
>>
>> --
>> "If it was so, it might be; and if it were so, it would be; but as it
>
>
> isn't,
>
>> it ain't. That's logic" -- Lewis Carroll
>>
>>
>
>
>
------------------------------------------------------------------------

/// <summary>
/// Top level exception handler. Future home of automatic bug report form and
add to bug database.
/// </summary>
internal class CustomExceptionHandler
{
// Handles the exception event.
public void OnThreadException( object sender, ThreadExceptionEventArgs t )
{
DialogResult result = DialogResult.Cancel;
try
{
result = this.ShowThreadExceptionDialog( t.Exception );
}
catch
{
try
{
MessageBox.Show( "Fatal Error", "Fatal Error",
MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
finally
{
Application.Exit();
}
}

// Exits the program when the user clicks Abort.
if( result == DialogResult.Abort )
Application.Exit();
}

// Creates the error message and displays it.
private DialogResult ShowThreadExceptionDialog( Exception e )
{
string errorMsg = "An error occurred please contact the adminstrator with the
following information:\n\n";
errorMsg = errorMsg + e.Message + "\n\nStack Trace:\n" + e.StackTrace;
return MessageBox.Show( errorMsg, "Application Error",
MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop );
}
}

[Jay B. Harlow [MVP - Outlook]]

Steel City Phantom,
In my windows service I normally wrap each "event" in a Try Catch & log the
exception in the Catch block. My Windows Service is based on a single
System.Timers.Timer, so its a simply matter of wrapping the Timer.Elapsed
handler in a Try/Catch.

I initially expected Timer.Elapsed to raise the AppDomain.UnhandledException
if it had an unhandled exception, however it currently is not working as I
would expect & I have not researched why not.

My Timer.Elapsed also uses ThreadPool.QueueUserWorkItem, The routine passed
is also wrapped in a Try/Catch so I'm not sure if QueueUserWorkItem uses
AppDomain.UnhandledException or not. I have not taken the time to research
ThreadPool & Unhandled Exceptions...

Hope this helps
Jay
"Steel City Phantom" <sc******@yaright.com> wrote in message
news:e2**************@TK2MSFTNGP11.phx.gbl...

your right, but the appdomain doesn't catch it and the application puts
it in an infinate loop.

now what.

Message by Justin Rogers <Ju****@games4dotnet.com> on: 11/4/2004 4:21:21
PM

I'd be careful thinking that way. OnThreadException is based around a
message
loop
and the exception being raised is from within a call-stack where the
message
loop is
somewhere lower. In some cases I believe there may be more hook-up going
on,
but not quite sure.

Maybe you should check out AppDomain.UnhandledException

<<snip>>