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 ArgumentNullExc eption (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**********@d iscussions.micr osoft.com> wrote in message
news:F8******** *************** ***********@mic rosoft.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
SwallowExceptio n. 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*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.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 ArgumentNullExc eption (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.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion 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.Thr eadException 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.Thr eadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.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 ArgumentNullExc eption (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******** ******@tk2msftn gp13.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.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion 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.Thr eadException 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.Thr eadException handler will catch all uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.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 ArgumentNullExc eption (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*******@hotm ail.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.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******** ******@tk2msftn gp13.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.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion 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.Thr eadException 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.Thr eadException handler will catch

all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.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 ArgumentNullExc eption (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*******@hotm ail.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.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******** ******@tk2msftn gp13.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.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion 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.Thr eadException 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.Thr eadException handler will catch

all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.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 ArgumentNullExc eption (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******** *****@TK2MSFTNG P11.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*******@hotm ail.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.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******** ******@tk2msftn gp13.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.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion 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.Thr eadException 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.Thr eadException handler will

catch all

uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.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 ArgumentNullExc eption (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
>
>