4

What is considered best practice associated with Exception Handling inside an ASP.NET HttpHandler? Should Exceptions not able to be handled be allowed to flow upwards through the chain as one would do in general or should all Exceptions be caught and "handled" in the handler and allow nothing past?

leppie
  • 115,091
  • 17
  • 196
  • 297
Dokie
  • 304
  • 3
  • 9

4 Answers4

2

My suggestion will be simple: if you cannot "fix the problem" then don't swallow the exception - let it propagate. Otherwise you'll most likely face with unexpected behavior of your application.

volpav
  • 5,090
  • 19
  • 27
  • This is what I thought too - I was conducting a code review where the "swallow" approach had been taken. There was also an incorrect comment in the code to say it was required so as not to crash IIS which made me wince! – Dokie Jul 07 '11 at 10:40
  • Nice, that reminded me of a project I took over with thousands of swallowed exceptions from this SO post: http://stackoverflow.com/questions/204814/is-there-any-valid-reason-to-ever-ignore-a-caught-exception and that's exactly what the developers I was working with said "It keeps the site from crashing" that's a BS excuse in my mind. – stephenbayer Jul 07 '11 at 11:00
  • 2
    While generally you should allow exceptions to bubble up to the top layer, the fact is an HttpHandler is the top layer, it is part of the UI and at that point you need to handle them gracefully. This is going to depend on what your handler is doing, obviously. If it's returning an image and the exception was caused by not finding data in the database, returning a HttpStatusCode of 401 is likely more appropriate. – Steve Sheldon Aug 08 '12 at 13:22
  • Oops, meant a 404 HttpStatusCode. – Steve Sheldon Aug 08 '12 at 13:34
2

All exceptions should be handled, somehow. You need to provide some sort of notification to the user that something went wrong, if an unexpected exception bubbles up past all your exception handlers. There should be some way to notify an admin or programmer (a log, email, or whatever) so that additional code can be added to handle the exception situation. You should try to handle any exceptions that will likely pop up, such as database connectivity issues in case the database goes down. Basically, you want to fail as gracefully as possible within the realm of what you can predict, and if unexpected occurrences occur, trouble shoot what happened, and add additional code to deal with those situations.

stephenbayer
  • 12,373
  • 15
  • 63
  • 98
1

Are you talking about HTTP Handlers or HTTP Modules? Because HTTP Handlers are just routine handlers (ASP.NET Pages are just simple HTTP Handlers)

Well, if you meant HTTP Handler, then as I said, it's just like a normal ASP.NET Page. What do you do in your page?

But there are some general guidelines that you have to consider always for exception handling:

  1. Never let the end user see the exception page (yellow screen of death). This means that you have to always try/catch or if your code to prevent exceptions from being rendered on the screen.
  2. Never swallow a exception. The least work you have to do in any catch block, is to log it.
  3. Have a centralized exception handling and message translate mechanism, so that your future maintenance is easier.
  4. Prefer validation and if checks over catching an exception, because catch blocks are expensive.

Why did everybody voted this post down. I just wanted to complete this post guys :)

Saeed Neamati
  • 35,341
  • 41
  • 136
  • 188
0

How you handle an exception depends on the particular scenario, but it should be handled somewhere to find out what went wrong.

You should log as much information as you possibly require (error codes, messages, stacktrace etc) to make it easier to recreate and rectify. You may also want to log lost information (such as any form details) or any security related information.

After the above is done you can just gracefully redirect to a relevant error page.

Lasse
  • 251
  • 1
  • 4