adding info to an exception

[Jeff]

hey

..NET 2.0

I'm wondering if tit's possible to add some info to an exception. lets say I
want to add "helloworld" to an exception so where it's caught can check for
this "helloword" text...

The reason I ask is that I'm programming a n-tier application and want
database errors to be caught in the data layer. but giving the user a
another errror. The user errortext is determined in the presentationlevel.
So when for exampel an error occur in the data layer the text "invalid
column" is written to the eventlog and the user get to show another error.

I know I can in the catch block throw another exception but that is not a
good solution....

any suggestions

 

[Nicholas Paldino [.NET/C# MVP]]

Jeff,

That's about the only solution you have, really. Why is it not a good
solution?

 

[Olie]

Throwing another exception is exactly what you are supposed to do. You
have probably read that re-throwing an exception is not recommended
for performance reasons. That refers to re-throwing the same
exception, it is perfectly OK to transform the exception into another
more descriptive exception and throw that.

The whole exception model is built around the capability to add more
information as the exception propagates down the chain. That is why
you have the InnerException property to allow you to build up
exceptions with more information.

The best method is to declare your own Exception class that inherits
from ApplicationException. When you call the constructor you pass the
old exception in along with your new more descriptive error message.
You can even add extra properties to store more information so you
could have a short and a long error message if you wanted. Then just
throw this exception.

 

[Jon Skeet [C# MVP]]

Throwing another exception is exactly what you are supposed to do. You
have probably read that re-throwing an exception is not recommended
for performance reasons. That refers to re-throwing the same
exception, it is perfectly OK to transform the exception into another
more descriptive exception and throw that.

I have no problem with rethrowing the same exception, if you need to
do some logging or something else before rethrowing. If you need to
add more information, of course, using an InnerException of the
original is a good plan as you say.

The whole exception model is built around the capability to add more
information as the exception propagates down the chain. That is why
you have the InnerException property to allow you to build up
exceptions with more information.

The best method is to declare your own Exception class that inherits
from ApplicationException.

Deriving from ApplicationException is discouraged these days - it
doesn't add anything useful, and just makes the inheritance chain
longer for no good reason. I'd just derive from Exception.

Jon

 

[Guest]

Jeff,
In Framework 2.0 and beyond, the Exception class has a Data property which
can contain name / value information. You can populate this with whatever
name=value items you want, and pick it up when the exception is processed /
handled farther up the call stack.
-- Peter
http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com