Handling Exceptions in an n-tier environment

[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

[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
"Raterus" <mo*********@suretar.reverse> wrote in message
news:eQ**************@TK2MSFTNGP09.phx.gbl...
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

[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

"Raterus" <mo*********@suretar.reverse> wrote in message
news:eQ**************@TK2MSFTNGP09.phx.gbl...
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

[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!

"Bryant Hankins" <bryanthankins@_NO_SPAM_hotmail.com> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl...

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



"Raterus" <mo*********@suretar.reverse> wrote in message
news:eQ**************@TK2MSFTNGP09.phx.gbl...
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

[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

"Karl" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net> wrote in message news:eR**************@TK2MSFTNGP09.phx.gbl...

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


"Raterus" <mo*********@suretar.reverse> wrote in message
news:eQ**************@TK2MSFTNGP09.phx.gbl...
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

[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...s/004118.shtml for a
great explanation :)

Karl

"Raterus" <mo*********@suretar.reverse> wrote in message
news:er**************@TK2MSFTNGP09.phx.gbl...
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

"Karl" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net> wrote in
message news:eR**************@TK2MSFTNGP09.phx.gbl...

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
"Raterus" <mo*********@suretar.reverse> wrote in message
news:eQ**************@TK2MSFTNGP09.phx.gbl...
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

[Raterus]

Good to know! Thanks, you have been very helpful!
--Michael

"Karl" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net> wrote in message news:u2*************@TK2MSFTNGP11.phx.gbl...

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...s/004118.shtml for a
great explanation :)

Karl

"Raterus" <mo*********@suretar.reverse> wrote in message
news:er**************@TK2MSFTNGP09.phx.gbl...
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

"Karl" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net> wrote in
message news:eR**************@TK2MSFTNGP09.phx.gbl...

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
"Raterus" <mo*********@suretar.reverse> wrote in message
news:eQ**************@TK2MSFTNGP09.phx.gbl...
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