Error/Exception handling

Jyothi_23 · April 1st, 2009, 04:05 PM

hi,

Can anybody please tell me how do we handle errors?
Suppose I dont want to show the default error page or any system generated message but want to show a custom message according to the exception I get.
How do we handle this? And is there anyway we can maintain log files so we would be able to open them while the application is in production.
I hope somebody please give some idea on this or any resource I can go through.
Thanks for the help!

Lee Dumond · April 1st, 2009, 05:50 PM

How long can you hold out?

I am just finishing up a new Wrox Blox that deals extensively with these very topics.

It should be available on the site in a couple of weeks.

Here is a brief blurb that describes the content.

Unravel the mysteries of exception handling in ASP.NET! After a detailed introduction to structured exception handling and exception propagation in the .NET Framework, youâll delve into a variety of practical topics such as: when, where, and how to properly throw, catch, and handle exceptions in your code; how to avoid triggering the most common CLR exceptions; handling exceptions in ASP.NET data sources, data-bound controls, and rich ASP.NET server controls; and processing unhandled exceptions at both the Page and Application levels. Weâll also walk through the building of a complete, reusable, and fully configurable ASP.NET exception processing framework that extends far beyond ASP.NETâs built-in error handling capabilities. Youâll learn how to collect information about the state of the application when the exception occurred; how to leverage various ASP.NET state-handling mechanisms such as Application, Context, Session, ASP.NET Cache, cookies, and querystrings to store and pass error data; create a friendly, informative, and highly functional custom error UI; show friendly error messages to ânormalâ visitors while showing detailed error reports only to site managers based on authentication, authorization, or IP; provide a way for users to add their own information to error reports; log and report errors via email, the Windows Event Log, XML files, or a custom database; and more. Once complete, youâll be able to quickly and easily add this new functionality to any web site you create using a simple .dll. A complete sample application and C# source code for the exception processing framework is available as a companion download.

jimibt · April 1st, 2009, 06:22 PM

Quote:

Originally Posted by Lee Dumond

How long can you hold out?

lee,

after that description - not long i reckon. sounds like a long overdue resource and one that i shall definately be grabbing when it's made available.

great stuff - especially as it's at framework level rather than 'instance' level. my issues have always been this 'apples and pears' (or is that oranges and bananas

) approach to enterprise level error handling and recovery. never totally committed to a universal approach, so i'm already relishing this as both an 'intellectual' read (don't place TOO much substance on the intellectual part :) and a practical approach to resolving my little exception grollies...

can't wait!!

Jyothi_23 · April 1st, 2009, 06:44 PM

Hello Lee,

Thanks very much for your response and the resource you will be providing.
I can hold out until your resource is made available.
But I have an interview in a couple of days so just wanted to find if there is any resouce that could help me with error handling / exception handling in the mean time.

Thanks again!

Lee Dumond · April 1st, 2009, 07:12 PM

I guess you could Google or check out the MSDN, though be careful... you will run into a lot of bad information on the 'Net about this topic. Lord knows I did.

Steve S · April 2nd, 2009, 12:48 PM

Lee,

Thanks for putting this together. I too am very interested in seeing it when it's available.

I know you follow Jeff Atwood so you may already know about an article and code he posted, now long ago, on CodeProject for .NET error/exception handling. It is specific to winforms, but at the code level error trapping should have many similarities whether web or winform. It might be worth a look for you, Jyothi and any others interested in the topic.

Steve

Lee Dumond · April 2nd, 2009, 01:12 PM

Ah yes Steve, that is an oldie-but-goodie, back from when Jeff actually used to sling code for a living.

His advice about when to catch / not catch is pretty good, though I think he is being somewhat namby-pamby about not catching System.Exception ("when possible"). I would go further and say that I cannot ever recall a situation where I thought it was a good idea.

In fact, I understand that the 4.0 version of the CLR is going to make it harder to catch(Exception) by issuing a compiler warning, and possibly even requiring the use of a special keyword to do it.

Lee Dumond · April 8th, 2009, 01:28 PM

Hello all,

In the interest of whetting your appetites, I am posting the TOC of this upcoming Blox:

Quote:

Introduction

What is an Exception?
The Exception Class
Property Members
Method Members

Structured Exception Handling
Handling Exceptions
Try-Catch
Type Filtering
Finally
Exception Propagation: Part 1
Throwing Exceptions

Exception Handling Best Practices
Defensive Programming
Validating Input
Checking for Error Conditions
Choosing the Right Exception to Throw
Exceptions Should Be Exceptional
Donât Abuse Exceptions
Avoid Swallowing Exceptions
Donât Try to Handle Everything

Other Exception Handling Scenarios
Handling Exceptions in ASP.NET Data Sources
Handling Exceptions in ASP.NET Data-Bound Controls
Handling Exceptions in ASP.NET Rich Server Controls

Managing Unhandled Exceptions in ASP.NET
Exception Propagation: Part 2
The ASP.NET Default Exception Handler
Page.Error and HttpApplication.Error

Building a Custom ASP.NET Exception Handler
The âFourth Coffeeâ Sample Site
The LD.ExceptionHandling Class Library
Custom Configuration
Handling and Redirecting
Collecting Information
Storing and Retrieving
Logging and Notification
Creating a Custom Error UI
The Error Page
Pages for HTTP Errors
The Admin Pages

Adding the Custom Exception Handler to Your Own Site

Conclusion

jimibt · April 8th, 2009, 07:38 PM

lee - is whetting the same as scaring

nah, seriously, looks good, can't honestly wait...

nice one

[edit] i come from a c/c++ background but actually used (due to commercail 'demand') vb3-6 immediately after 'learning' the mfc framework. as a result, in vb i tended to always 'test' for errors, rather than using vb's very weak 'on error' primitive. in c#, altho' i do use try/catch/finally blocks, i do feel that i tend to revert back to those same 'tests' in the language and have always been looking for an error handling framework to take me beyond those limiting boundaries.

in a nutshell, if you can deliver this, you've addressed a longstanding ommission in my .net arsenal... yow

Lee Dumond · April 8th, 2009, 08:19 PM

Quote:

Originally Posted by jimibt

in vb i tended to always 'test' for errors, rather than using vb's very weak 'on error' primitive. in c#, altho' i do use try/catch/finally blocks, i do feel that i tend to revert back to those same 'tests' in the language

In the Blox, I explain that in many cases, "testing" for conditions which might throw an exception, and coding around those conditions, is actually more efficient than handling the exception. For example:

Code:

public double Average
{
get
{
 try
 {
    return (double) Total / Num;
 }
 catch (DivideByZeroException)
 {
    return 0.0;
 }
}
}

Code:

public double Average
{
get
{
  if (Num == 0)
  {
     return 0.0;
  }
  else
  {
     return (double) Total / Num;
  }
}
}

These two get accessors accomplish the same thing.

If you expect, given the conditions under which this property is normally evaluated, that Num == 0 will be a rather common "non-exceptional" state of affairs, then #2 is better.

However, if conditions are such that Num is not normally expected to be zero (in other words, Num == 0 would be considered an "exceptional" case), then #1 is better.

Again, this is explained in more detail in the Blox, along with a presentation of other common scenarios in which programmatic error checking can be the superior option.