Correct way of handling exceptions?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

What's the correct way of using try...catch in my web application? For
example, if I catch a connection error or something with the DB, how am I
supposed to bubble it up to the web interface?
Is there a correct way?

Thanks for the help.
 
It laregely depends on how you have coded your site. You can have exceptions
caught in the Application_error and simply redirect a user.

If, instead, you think you can handle the error, you can set up a try ...
catch. If you cannot solve the error, the only reason to catch is to display
an error on the problem page. This is only useful, IMO, if you have some
bits working and others not. Otherwise, you are merely keeping the user on a
broken page.

In most cases, unless I am logging, I try ... finally and allow a bubble up
to the UI. Then, I just make sure the user has a nice error page, like
Orkut's "bad server, no cookie" error page.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************************************************
Think outside of the box!
*************************************************
 
A try/catch block simply gives you a chance to handle an exception in some
way. The exception can be rethrown, or handled in any other way you wish.
*How* you handle it depends largely upon what type of exception was thrown,
and what sort of recovery (if any) can be made. Now, as for type, every type
of exception *is* a type, and you can use multiple catch blocks, one for
each possible type of exception you anticipate, even one that catches
System.Exception, to catch any exceptions that are not caught by other catch
blocks. Of course, the more specific types should be caught first, so that
the catch-all catch block doesn't catch any of them before they get a chance
to.

For example, in your case, you might put in a catch block for a
SqlException:

private static void OpenSqlConnection(string connectionString)
{
using (SqlConnection connection = new SqlConnection(connectionString))
{
try
{
connection.Open();
}
catch (SqlException sqlEx)
{
// do something about the connection error,
// such as informing the user
}
catch (Exception ex)
{
// do something else.
{
}
}

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.
 
VMI,

You actually don't have to catch everything in the lower levels.

try
{
}
finally
{
}

//no catch

Do a google search for "try catch finally Brad Abrams" and you'll find some
tidbits about this.

In a web environment, here is what I do.

In the DataLayer, I just write try/finally's

public class EmpData
{

public void UpdateEmployee(DataSet ds)
{
try
{
//code up and run some stored procedure
}
finally
{
//clean up resource use
}
}

}

In the BusinessLayer, I ~sometimes catch the exception, and create my own
"more friendlier" exception

try
{

}
catch (System.Data.SqlException)
{
throw new MyCustomException("Houston, the database is experiencing
some issues." , ex);
}
catch (Exception ex)
{
throw new MyCustomException("Houston, this is a friendly error
regarding having a problem." , ex);
}


Creating or subclassing your own Exception is not hard. I usually have a
constructor which takes another exception....




In the webpage, in the code behind .... I have this

try
{
''do something
}
catch (Exception ex)
{
//Maybe a response.write OR a direct to a common exception showing
page
Response.Write (ex.Message);
if(null!=ex.InnerException)
{
Response.Write (ex.InnerException.Message);
}
}


The reason you might write a MyCustomException ... is to push up a more
"friendlier" Message to the user.
Like, if the database fails on a constraint violation, you can intercept
that, and give a more "The age of the person violates a database constraint"
or something like that.

However, if Presentation layer means "presentation", perhaps you could catch
the exception there, and re-word it.
I prefer the biz layer.


I actually write many many more
try/finally

instead of

try
catch (Exception ex)
{
throw;
}
finally
{

}


If you're not going to do anything but catch it, then rethrow it, then don't
waste the effort. Just don't write in a "catch" in the try/finally

PS

If you do catch an exception remember

catch(Exception ex)
{
throw ex;//erases the StackTrace
}

VS

catch(Exception ex)
{
throw;//retains the StackTrace
}


You can test it, but the first one erases the StackTrace.
The second one retains the StackTrace.

That's a nice little nugget to be aware of.

PPS

The Exception Publishing Application Block is a nice add in.
I've written a custom publisher which
Writes out an error log
Sends an email.
Updates a database.

http://www.microsoft.com/downloads/...FamilyID=8CA8EB6E-6F4A-43DF-ADEB-8F22CA173E02

The built in , default functionality is to write to the EventLog.

The Enterprise Library has an updated version, but I still find the this
version of the EMAB useable.
 
Is there a correct way?
Click to expand...

Yes there is - and it's up to you to decide what it is... :-)

In addition to the others' replies, I tend to have a rule that base classes
catch errors but don't handle them - they simply rethrow them so that's it
up to the the caller class to handle them and take appropriate action. E.g.
I have a database abstraction layer base class where the methods have lots
of try...catch...finally blocks looking specifically for SqlException errors
e.g. no connectivity, wrong password etc. If one of these errors occurs the
process stops and the error is rethrown so that the caller can process it.
 
i'm not actually one to comment, as I don't have any official training in
asp.net other than online resources, but I've been coding for some time
now...anyway, history aside, when I discovered the Try command in asp.net, i
found it most awesome. so i created an aspx page (errorpage.aspx) and
everytime I trapped a critical exception, i would redirect to the errorpage
with the type (either db, email, filesystem, etc.) and ex.message, the
errorpage.aspx would log the error in the eventlog (for adm's) and greet the
user with a friendly error and if the error was not email, would email the
adm that there was an error on the page.
 
Back
Top