Best practice error handling?

  • Thread starter Thread starter gnewsgroup
  • Start date Start date
G

gnewsgroup

I am wondering what's considered the best practice error handling in
asp.net.

I know that each application is different and thus has different
requirement. So, let's say in general what is considered the best.

1. I know that we can handle errors in the catch block. But, I think
it is a lot of hassle to handle each exception separately.

2. I know that we can handle an exception of a particular page in the
Page_Error method or specify a file for the ErrorPage property in the
Page directive of an aspx page.

3. It is also possible to handle an exception in the Application_Error
method of global.asax file.

4. Finally, at the highest level, an exception can be handled by
specifying a redirect file for the customErrors element in web.config.

My question is this:

since we can handle an exception at the page, application level, is it
necessary to handle it in the catch block?

Thanks.
 
Heres a great read:

http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx


I feel you should be writing a heck of alot more

try
{

}
//no catch
finally
{

}


blocks...then try/catch blocks. And handle most of the exception handling
at higher levels.

...

One situation to deviate is like this


try
{
//call datalayer
}
catch (SqlException sqlex)
{
throw new MyCustomExceptionFriendlyDatabaseNotAvailableException("The db
is currently unavailable", sqlex);
}

IF you want to not show technical exceptions to the end user, but rather
something else.


But the url above is a great read.
 
The rule of thumb.
Never catch an exception if you do not know what to do with it....

As strange as it sounds here are couple live examples....

1. You are trying to run sql statement and DB is not responding. Hence you
get an exception....
You do not handle it in try... catch.... right there cause you can not
recover.
You do not handle it in Page_Error cause I would think all pages must behave
the same in this case. So this is not page specific.
You DO handle it in Application_Error... And most likely the behaviour is
that you Email/Beep pager to admin, Log an actual error message, redirect to
"Please come back later".htm

2. Your user entered "AAA" as his age. So your validation code trying to do
Int32.Parse(txtAge.Value).. You get exception.

You do handle it in try...catch right there. Cause you know what to do right
there. Simply show an error message to the user to enter his correct age.

George.
 
1. You are trying to run sql statement and DB is not responding. Hence you
get an exception....
You do not handle it in try... catch.... right there cause you can not
recover.
Click to expand...

??? Why not...?
 
Well, you are free to do anything of course but from my experience
application can not recover after database error.
All it can do is to notify admin and show user polite message "come back in
2 hours. We are updating our servers".

George.
 
In addition to other responses, you can also AFAIK use a try/finally block
(without the catch clause). It allows to perform additional cleanup but let
the global handler process the exception.

You can also examine the exception in a catch clause and use throw with no
arguments to let the global exceptino handler doing this...

Basically the idea would be to start by using a global exception handler and
then adding local code if you have something to do locally when an exception
occurs...
 
Well, you are free to do anything of course but from my experience
application can not recover after database error.
Click to expand...

Fair enough - I've never had a problem with it...
 
Maybe you should snip less and read more.
Click to expand...

Please explain to me how a method cannot recover from an error indicating
that a database e.g. SQL Server is not responding...

That's what SqlException is for, no...?
 
I am afraid that there is a confusion in terminology.
When I said "can not recover" it means that applications is completely
unworkable and all has left is to shut it down.
IT DOES not mean that user should not see "nice" error message.

From that point SQL errors are (usually) non-recoverable exceptions.

George.
 
Please explain to me how a method cannot recover from an error indicating
that a database e.g. SQL Server is not responding...

That's what SqlException is for, no...?
Click to expand...

I guess it depends on what you mean by "recover". I think it's beyond the
capabilities of most applications to troubleshoot the network, restart the
DB server, etc. So "recover" in terms of generating desired output is out of
the question. You can (and should) "recover" in terms of generating an error
message to the user, which is what George said (and you snipped).
 
I am afraid that there is a confusion in terminology.
When I said "can not recover" it means that applications is completely
unworkable and all has left is to shut it down.
IT DOES not mean that user should not see "nice" error message.
Click to expand...

OK.
 
In addition to other responses, you can also AFAIK use a try/finally block
(without the catch clause). It allows to perform additional cleanup but let
the global handler process the exception.

You can also examine the exception in a catch clause and use throw with no
arguments to let the global exceptino handler doing this...

Basically the idea would be to start by using a global exception handler and
then adding local code if you have something to do locally when an exception
occurs...
Click to expand...

Great discussion. I sorta like this idea to go from the higher level
down to the lower level, which saves a lot of hassle handling each
individual exception separately.
 
Back
Top