How to handle exceptions in a library dll?

[Author]

I am writing a small library in C#, which will be compiled to dll and
shared by multiple applications.

This is sorta new to me. I am wondering how professionals handle
exceptions in a dll library.
Should we simply catch it, re-throw it, and leave the handling to the
consumer class? This what I have been doing, but not sure if this is
considered a standard way of doing it.

Thank you if you could give me little hint.

[Peter Duniho]

On Thu, 24 Jul 2008 19:48:03 -0700, Author <gn********@gmail.comwrote:

I am writing a small library in C#, which will be compiled to dll and
shared by multiple applications.

This is sorta new to me. I am wondering how professionals handle
exceptions in a dll library.
Should we simply catch it, re-throw it, and leave the handling to the
consumer class? This what I have been doing, but not sure if this is
considered a standard way of doing it.

Ideally, you would only throw exceptions related to the caller's input.
And you would do so at the point of checking the input, rather than
waiting for bad input to cause an exception later.

In some cases, you won't know the caller's input is bad until you try to
use it. In those cases, there may be some value in catching the
exception, using it as the inner exception for a new exception that is
descriptive and useful to the caller and throwing that new exception.

Other than that, I think there's not much point in catching and rethrowing
exceptions. If you don't have something useful to do with the exception,
don't catch it at all. Just let it go all the way back to the caller
instead.

Pete

[Duggi]

On Jul 25, 7:54*am, "Peter Duniho" <[e-mail]>
wrote:

On Thu, 24 Jul 2008 19:48:03 -0700, Author <[e-mail]:

I am writing a small library in C#, which will be compiled to dll and
shared by multiple applications.

This is sorta new to me. *I am wondering how professionals handle
exceptions in a dll library.
Should we simply catch it, re-throw it, and leave the handling to the
consumer class? *This what I have been doing, but not sure if this is
considered a standard way of doing it.

Ideally, you would only throw exceptions related to the caller's input. *
And you would do so at the point of checking the input, rather than *
waiting for bad input to cause an exception later.

In some cases, you won't know the caller's input is bad until you try to *
use it. *In those cases, there may be some value in catching the *
exception, using it as the inner exception for a new exception that is *
descriptive and useful to the caller and throwing that new exception.

Other than that, I think there's not much point in catching and rethrowing *
exceptions. *If you don't have something useful to do with the exception, *
don't catch it at all. *Just let it go all the way back to the caller *
instead.

Pete

Pete approach is excellent.

-Cnu

[Author]

On Jul 24, 10:54*pm, "Peter Duniho" <[e-mail]>
wrote:

On Thu, 24 Jul 2008 19:48:03 -0700, Author <[e-mail]:

I am writing a small library in C#, which will be compiled to dll and
shared by multiple applications.

This is sorta new to me. *I am wondering how professionals handle
exceptions in a dll library.
Should we simply catch it, re-throw it, and leave the handling to the
consumer class? *This what I have been doing, but not sure if this is
considered a standard way of doing it.

Ideally, you would only throw exceptions related to the caller's input. *
And you would do so at the point of checking the input, rather than *
waiting for bad input to cause an exception later.

In some cases, you won't know the caller's input is bad until you try to *
use it. *In those cases, there may be some value in catching the *
exception, using it as the inner exception for a new exception that is *
descriptive and useful to the caller and throwing that new exception.

Other than that, I think there's not much point in catching and rethrowing *
exceptions. *If you don't have something useful to do with the exception, *
don't catch it at all. *Just let it go all the way back to the caller *
instead.

Pete

Great. Seems my intuition is correct. In one class of my library, I
need to return a bool. I set the bool variable to false in the catch
block and then throw the exception. I think this exception re-throw
makes sense, since I need to reset the value of the bool variable
before I return it.

[Jon Skeet [C# MVP]]

On Jul 25, 2:14*pm, Author <[e-mail]:

Great. Seems my intuition is correct. *In one class of my library, I
need to return a bool. *I set the bool variable to false in the catch
block and then throw the exception. *I think this exception re-throw
makes sense, since I need to reset the value of the bool variable
before I return it.

If you're rethrowing the exception, you're not returning the value
anyway though.

Jon

[Author]

On Jul 25, 9:20*am, "Jon Skeet [C# MVP]" <[e-mail]:

On Jul 25, 2:14*pm, Author <[e-mail]:

Great. Seems my intuition is correct. *In one class of my library, I
need to return a bool. *I set the bool variable to false in the catch
block and then throw the exception. *I think this exception re-throw
makes sense, since I need to reset the value of the bool variable
before I return it.

If you're rethrowing the exception, you're not returning the value
anyway though.

Jon

Yes, that's correct. I didn't realize it.

[G.S.]

On Jul 25, 10:55*am, Author <[e-mail]:

On Jul 25, 9:20*am, "Jon Skeet [C# MVP]" <[e-mail]:

On Jul 25, 2:14*pm, Author <[e-mail]:

Great. Seems my intuition is correct. *In one class of my library, I
need to return a bool. *I set the bool variable to false in the catch
block and then throw the exception. *I think this exception re-throw
makes sense, since I need to reset the value of the bool variable
before I return it.

If you're rethrowing the exception, you're not returning the value
anyway though.

Jon

Yes, that's correct. *I didn't realize it.

I will dare to express slightly different opinion.
It's proven very valuable to me to always catch and rethrow the
exception, adding as much information (without compromising
application security) as possible.

I absolutely HATE to see an error (happens a lot w/ microsoft's
products of all kinds) saying "Something bad happened". Why not say
what exactly, where, what were the values of the incoming parameters,
intermediate values, even how far down the execution path it happened?
That info is usually not available in the original exception (or inner
exception).

Yes, if you are able to debug, you can step through and see all that.
Adding it to the re-thrown exception only may speed up your
development a bit, but the real value comes at run time.

Then let the client decide how much of the info and how to use it.

I hope I am not too much off and only trying to bring another
perspective

Regards:
G.S.