Error Handling - Best Practices

[Sandy]

Hello -

I read an interesting article on the web wherein the author states he
doesn't handle too many errors at page level, but handles them at the
application level. He further goes on to show how error logging can be
incorporated using a Sql Server log with an additional text log in case Sql
Server was down.

My inclination after reading the article is to use Try-Catch-Finally as
little as possible (tends to slow things if you have too many?) and rely on
the application level.

Is this considered a "best practice"? If not, why?

Any help will be appreciated!
--
Sandy

[Brock Allen]

> I read an interesting article on the web wherein the author states he

doesn't handle too many errors at page level, but handles them at the
application level. He further goes on to show how error logging can
be incorporated using a Sql Server log with an additional text log in
case Sql Server was down.
Yes, the Application_Err or event handler in global.asax is a great place
to log unhandled exceptions. Any exception that isn't specifically caught
in your application somewhere will end up at Application_Err or. This allows
you to be proactive about finding latent bugs and other bad things in your
application.
My inclination after reading the article is to use Try-Catch-Finally
as little as possible (tends to slow things if you have too many?) and
rely on the application level.
try/catch blocks are not slow when there is no exception. It's only when
an exception happens that they tend to run slower because of the stack unwinding
that has to be done. But if it only happens in an exception case, then this
isn't a problem. Also, if the operation failed, then it's not a problem to
take a bit of extra time to be able to recover from it (again, assuming this
isn't the expected path of frequent execution). finally blocks really don't
execute any faster or slower in either situation.
Is this considered a "best practice"? If not, why?

Personally, I only handle exceptions (via catch) when I know that I can write
code to recover from the exception. This isn't common, actually... How do
you, in code, recover from a database connectivity exception? Things like
that are very hard to handle. Database timeouts? Well, that's a bit harder...
perhaps it's possible to resubmit the SQL, but then maybe it's not (especially
if you're in a larger transaction). So really, I just judge it case by case.

I always use finally blocks when I need a guarentee that a certain code block
execute (primarily to do resource cleanup like close DB connections).

-Brock
DevelopMentor
http://staff.develop.com/ballen

[Ye]

There is a difference between error handling and error reporting.

If you are talking about error handling I don't think there is a better way
other than using try-catch. When saying that try-catch is slow, one is
usually comparing it to using an if statement to catch the condition that
will cause the error before an error is thrown. It is good practice to try to
catch an error-causing condition instead of catching the exception.

If you are talking about error reporting, I personally like ELMAH, written
by Atif Aziz, the best. Scott Mitchell wrote an excellent article about it
here
http://msdn.microsoft.com/library/de...html/elmah.asp.
It's easy to setup and REALLY reusable. It is decoupled from your application
and no re-compilation of your website is necessary.

Hope this helps.
Cheng Yuan Yap Ye
http://kuantanzai.blogspot.com
"Brock Allen" wrote:

I read an interesting article on the web wherein the author states he
doesn't handle too many errors at page level, but handles them at the
application level. He further goes on to show how error logging can
be incorporated using a Sql Server log with an additional text log in
case Sql Server was down.

Yes, the Application_Err or event handler in global.asax is a great place
to log unhandled exceptions. Any exception that isn't specifically caught
in your application somewhere will end up at Application_Err or. This allows
you to be proactive about finding latent bugs and other bad things in your
application.

My inclination after reading the article is to use Try-Catch-Finally
as little as possible (tends to slow things if you have too many?) and
rely on the application level.

try/catch blocks are not slow when there is no exception. It's only when
an exception happens that they tend to run slower because of the stack unwinding
that has to be done. But if it only happens in an exception case, then this
isn't a problem. Also, if the operation failed, then it's not a problem to
take a bit of extra time to be able to recover from it (again, assuming this
isn't the expected path of frequent execution). finally blocks really don't
execute any faster or slower in either situation.

Is this considered a "best practice"? If not, why?

Personally, I only handle exceptions (via catch) when I know that I can write
code to recover from the exception. This isn't common, actually... How do
you, in code, recover from a database connectivity exception? Things like
that are very hard to handle. Database timeouts? Well, that's a bit harder...
perhaps it's possible to resubmit the SQL, but then maybe it's not (especially
if you're in a larger transaction). So really, I just judge it case by case.

I always use finally blocks when I need a guarentee that a certain code block
execute (primarily to do resource cleanup like close DB connections).

-Brock
DevelopMentor
http://staff.develop.com/ballen

[Sandy]

Thanks, Brock!

"Brock Allen" wrote:

I read an interesting article on the web wherein the author states he
doesn't handle too many errors at page level, but handles them at the
application level. He further goes on to show how error logging can
be incorporated using a Sql Server log with an additional text log in
case Sql Server was down.

Yes, the Application_Err or event handler in global.asax is a great place
to log unhandled exceptions. Any exception that isn't specifically caught
in your application somewhere will end up at Application_Err or. This allows
you to be proactive about finding latent bugs and other bad things in your
application.

My inclination after reading the article is to use Try-Catch-Finally
as little as possible (tends to slow things if you have too many?) and
rely on the application level.

try/catch blocks are not slow when there is no exception. It's only when
an exception happens that they tend to run slower because of the stack unwinding
that has to be done. But if it only happens in an exception case, then this
isn't a problem. Also, if the operation failed, then it's not a problem to
take a bit of extra time to be able to recover from it (again, assuming this
isn't the expected path of frequent execution). finally blocks really don't
execute any faster or slower in either situation.

Is this considered a "best practice"? If not, why?

Personally, I only handle exceptions (via catch) when I know that I can write
code to recover from the exception. This isn't common, actually... How do
you, in code, recover from a database connectivity exception? Things like
that are very hard to handle. Database timeouts? Well, that's a bit harder...
perhaps it's possible to resubmit the SQL, but then maybe it's not (especially
if you're in a larger transaction). So really, I just judge it case by case.

I always use finally blocks when I need a guarentee that a certain code block
execute (primarily to do resource cleanup like close DB connections).

-Brock
DevelopMentor
http://staff.develop.com/ballen

[Sandy]

Thanks, Ye. Scott Mitchell is one of my favorites.

Sandy

"Ye" wrote:

There is a difference between error handling and error reporting.

If you are talking about error handling I don't think there is a better way
other than using try-catch. When saying that try-catch is slow, one is
usually comparing it to using an if statement to catch the condition that
will cause the error before an error is thrown. It is good practice to try to
catch an error-causing condition instead of catching the exception.

If you are talking about error reporting, I personally like ELMAH, written
by Atif Aziz, the best. Scott Mitchell wrote an excellent article about it
here
http://msdn.microsoft.com/library/de...html/elmah.asp.
It's easy to setup and REALLY reusable. It is decoupled from your application
and no re-compilation of your website is necessary.

Hope this helps.
Cheng Yuan Yap Ye
http://kuantanzai.blogspot.com
"Brock Allen" wrote:

I read an interesting article on the web wherein the author states he
doesn't handle too many errors at page level, but handles them at the
application level. He further goes on to show how error logging can
be incorporated using a Sql Server log with an additional text log in
case Sql Server was down.

Yes, the Application_Err or event handler in global.asax is a great place
to log unhandled exceptions. Any exception that isn't specifically caught
in your application somewhere will end up at Application_Err or. This allows
you to be proactive about finding latent bugs and other bad things in your
application.

My inclination after reading the article is to use Try-Catch-Finally
as little as possible (tends to slow things if you have too many?) and
rely on the application level.

try/catch blocks are not slow when there is no exception. It's only when
an exception happens that they tend to run slower because of the stack unwinding
that has to be done. But if it only happens in an exception case, then this
isn't a problem. Also, if the operation failed, then it's not a problem to
take a bit of extra time to be able to recover from it (again, assuming this
isn't the expected path of frequent execution). finally blocks really don't
execute any faster or slower in either situation.

Is this considered a "best practice"? If not, why?

Personally, I only handle exceptions (via catch) when I know that I can write
code to recover from the exception. This isn't common, actually... How do
you, in code, recover from a database connectivity exception? Things like
that are very hard to handle. Database timeouts? Well, that's a bit harder...
perhaps it's possible to resubmit the SQL, but then maybe it's not (especially
if you're in a larger transaction). So really, I just judge it case by case.

I always use finally blocks when I need a guarentee that a certain code block
execute (primarily to do resource cleanup like close DB connections).

-Brock
DevelopMentor
http://staff.develop.com/ballen