Freigeben über

Questions about .net Exceptions

  • Artikel

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

  • Anonymous
    April 02, 2008
    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?

  • Anonymous
    April 02, 2008
    The comment has been removed

  • Anonymous
    April 04, 2008
    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

  • Anonymous
    April 06, 2008
    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

  • Anonymous
    April 06, 2008
    The comment has been removed

  • Anonymous
    April 06, 2008
    do you have any method to do like that?

  • Anonymous
    January 17, 2009
    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.

  • Anonymous
    January 17, 2009
    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.

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