Handling Exceptions in an n-tier environment

R

Raterus

Hello,

I'm trying to hop on the n-tier/OOP bandwagon for my applications, but I've hit one snag that I'm not sure the best way to proceed. Say a SqlException is raised in my Data Access layer, that is a long long way from my presentation layer/aspx page, where I would at least like to print out a notification that an error was raised. How can I best achieve this in an n-tier environment. It seems if I handle the error in my Data Access layer, by the time the code execution gets back to the presentation layer, it won't know what happened. Should I be defining my own object exceptions, and raise them when I catch an error, and let it propigate itself up the pipeline until the presentation layer can handle it?

Any help would be greatly appreciated!
--Michael
 
K

Karl

Statement: "It seems if I handle the error in my DAL"
Question: Can you actually handle the error (like, hit a backup database, or
hit a cache which might be stale but will give some information) or can you
just swallow it?

I ask because my guess is that you can't actually handle it at the DAL
layer - all you can do is catch it at the presentation layer and display a
friendly error message. At that point, you have two options:

1 - let the exception bubble up (either don't catch it, or have an empty
throw (don't do a Throw ex))
2 - If, and only if, you can add additional information to the exception,
rethrow a new exception (custom or not) making sure to include the original
exception in there. (throw new ApplicationException("Doh",
originalException))

Karl


Hello,

I'm trying to hop on the n-tier/OOP bandwagon for my applications, but I've
hit one snag that I'm not sure the best way to proceed. Say a SqlException
is raised in my Data Access layer, that is a long long way from my
presentation layer/aspx page, where I would at least like to print out a
notification that an error was raised. How can I best achieve this in an
n-tier environment. It seems if I handle the error in my Data Access layer,
by the time the code execution gets back to the presentation layer, it won't
know what happened. Should I be defining my own object exceptions, and
raise them when I catch an error, and let it propigate itself up the
pipeline until the presentation layer can handle it?

Any help would be greatly appreciated!
--Michael
 
B

Bryant Hankins

This is often handled exactly how you describe at the end of your post. The
data layer SqlException bubbles up to the Business Object layer which then
wraps that exception and re-raises with a more friendly strongly-typed
exception like OrderAddException when trying to call Order.Add. The
presentation layer (.aspx pages) then handles the OrderAddException and
presents a friendly message to the user like "Could not place your Order.
Please contact support here...."

--
Hope this helps,
Bryant Hankins
Numinet Systems Inc.
http://www.numinet.com/blogging



Hello,

I'm trying to hop on the n-tier/OOP bandwagon for my applications, but I've
hit one snag that I'm not sure the best way to proceed. Say a SqlException
is raised in my Data Access layer, that is a long long way from my
presentation layer/aspx page, where I would at least like to print out a
notification that an error was raised. How can I best achieve this in an
n-tier environment. It seems if I handle the error in my Data Access layer,
by the time the code execution gets back to the presentation layer, it won't
know what happened. Should I be defining my own object exceptions, and
raise them when I catch an error, and let it propigate itself up the
pipeline until the presentation layer can handle it?

Any help would be greatly appreciated!
--Michael
 
R

Raterus

That makes a lot of sense, I was actually experimenting with this method before I received any answers, and it works very well. Thanks!
 
R

Raterus

hmm, Is there a good reason why I shouldn't issue a throw ex?

Try
somethingThatCanCauseAnError()
Catch ex As Exception
Throw ex
End Try

I can understand creating a new ApplicationException with additional details, but sometimes all I need is the original exception details.

Thanks for your help,
--Michael
 
K

Karl

Throw ex rebundles the exception...I agree that what you want is the
original exception, that's what plain Throw does ...

If the exception thrown was an SqlException,you'll rethrow an Exception.
The original exception is still available in InnerException...but since you
you havent' added your own information, all you've managed to do is
obfuscate the important stuff.

Check out: http://dotnetguy.techieswithcats.com/archives/004118.shtml for a
great explanation :)

Karl

hmm, Is there a good reason why I shouldn't issue a throw ex?

Try
somethingThatCanCauseAnError()
Catch ex As Exception
Throw ex
End Try

I can understand creating a new ApplicationException with additional
details, but sometimes all I need is the original exception details.

Thanks for your help,
--Michael
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top