Questions about .net Exceptions


One of my readers emailed me the following question

I have a simple questions that my management asks me. When I see all kinds of exceptions thrown (null exceptions etc..), what is the user experience? Does their system hand these back to the user? does it return an error message? or simply crashes?

How can I determine the user experience pertaing to these exceptions?

My answer

The answer depends very much on the type of exception that is thrown, where it is thrown from and of course if it is caught or not.

In the eventviewer (if running .net 2.0) you will see all exceptions that are thrown. 

Case #1

Most applications throw a number of NullReference exceptions because they have code similar to this one

try{
  UserName = Request.Cookies["UserName"].Value;   
}
Catch(Exception ex){
  // handle the exception
}

In this case, if Request.Cookies["UserName"] does not exist, you will of course throw a NullReferenceException when trying to do .Value, but the code handles it, so if this is the case then the answer is, no, the user will not see an error page or get an exception but depending on the logic on your site it might cause issues in other places.   The preferred way here would be to check if  Request.Cookies["UserName"] is null before doing .Value on it to avoid the nullref and handle the situation correctly. 

Basic rule of thumb, if a value may or may not be null, check if it is null before using it to avoid throwing an exception.

Case #2

If the code above was in an aspx page and you do not have try/catch around it then it would display an error message to the user.  It might be the exception/stack page if you havent turned <customErrors> in web.config, or a custom errors page if you have that set up.

In this case you will see an HttpUnhandledException in the eventlog.

Case #3

If the code above (or any code resulting in an exception) is running in a winforms, windows service app or on a non-request thread (timer thread, finalizer etc.) in ASP.NET it will crash the process unless you have turned on legacy exception handling.  If you are on 1.1. or use legacy exception handling in 2.0 it will not crash the ASP.NET service, instead it will stop processing at the sight of the exception leaving potential room for memory leaks etc. to occurr (if the excception occurred before cleaning up all native resources).  

Laters,
Tess

Comments (9)

  1. Jesper says:

    This seems pretty clear – but I think it is best practice (or at least Code Analysis and FxCop says so) not to catch the general Exception but you should catch a specific exception – like NullReferenceException.

    How can you handle this? Do we have to predict every exception which can occur in the code?

  2. Tess says:

    the short answer is yes, as a developer you should probably anticipate what exceptions that can occurr in your code if you want it to run correctly.   MSDN help shows what exceptions can occurr in different methods.

    It may not always be feasible to know all types of exceptions that occurr in which case you could have multiple handlers, one more specific first and then end off with a more generic one.  But in reality the generic one should only be for exceptions that you really cant predict.

  3. baal says:

    I got an Exception like below:

    Exception information:

       Exception type: HttpRequestValidationException

       Exception message: A potentially dangerous Request.Form value was detected from the client (CompanyIntroduce="…a you buy <a href= http://buys…").

    How I can deal this Exception in try/catch? because this happen when post data(with html tags) to another page. I don’t want to redirect to the custom errors page or show the exception/stack  on the page

  4. Tess says:

    Baal,  if you yourself is sending script tags then you have to remove the validation, but i would avoid sending script tags in the first place.

    To handle it you would have to handle it something like this…

    http://www.romsteady.net/blog/2007/06/how-to-catch-httprequestvalidationexcep.html

  5. baal says:

    This is not I want. "Rom’s Rants" blog is the same way as ustom errors page.

    in the

    try{

    UserName1 = Request.Cookies["UserName1"].Value;

    UserName2 = Request.Cookies["UserName2"].Value;  

    }

    catch

    {

    }

    if line of UserName2 has exception, the UserName1 value I still have.

    what I want is : post data from a page to b page, some data is saved(soted in local var),when HttpRequestValidationException happen, lost data after it.

    so, this is why I want use try/catch

  6. baal says:

    do you have any method to do like that?

  7. Daniel says:

    I have a quick question.

    If an app has started a thread that for some reason throws an exception shouldn’t the Application_error in Global.Asax, or HttpApplication.Error catch this?

    I would think so, but that appears not necesarrily to be the case.

    This is a problem because exceptions from a non-request thread will apparently propagate to w3wp and recycle the application pool.

  8. Tess says:

    the application_error will only catch it if it is happens on a request.  If you start your own thread you are correct in that it will crash if you throw an exception and don’t handle it, so if you create your own threads you need to make sure to set up try/catch blocks if there is a chance that it will throw an exception.

  9. Since a .net exception is a .NET object like any other, it gets stored on the GC heap when you (or some

Skip to main content