1

I have asked a few questions on here and read a few articles around exception handling but don't think I'm really grasping when you should and when you shouldn't handle an exception. From the articles I've read it states to "only handle exceptions you can recover from" What does it mean by that. If I can't handle the exception what do I do? Let it propagate back up the stack? If I don't handle it how can I log it and present a user friendly error message. What do most people do in web apps and web services?

As an example say I have a lower tier data layer that pulls data from sql

try{ //do something with db }catch(SqlException ex){ //what should i do here //should i call code again to retry getting data from db }catch(Exception ex){ //should i even catch exception of type exception }

How do I handle exceptions in lower tiers? Should I just let the exception bubble up the tiers? If so then if I want to catch an exception of type sqlexception then I need a reference to the library sqlexception is part of but surely I shouldn't have to reference that library in a layer that has nothing to do with data access.

Improve this question
2

3 Answers 3

Reset to default
2

Some simple ground rules:

  • Handling an exception requires that the state of your program is exactly the same as it was before the code got started that caused the exception. You will need lots of catch and finally blocks that restore variables back to their initial state.

  • Only consider handling an exception if catching it allows the program to continue running in a meaningful way. Hard to do anything useful when the database server is off line for example, might as well stop the program.

  • If you need a human to take corrective action (you almost always do) then be sure that she has enough information to troubleshoot the problem. Let exceptions bubble up to the UI layer. Avoid interpreting exceptions (no "Could not update the database" for example), display the exact exception message and stack trace.

  • Implement a handler for AppDomain.CurrentDomain.UnhandledException and log or display the value of e.ExceptionObject. Helps to diagnose unhandled exceptions. And helps you avoid putting catch everywhere.

  • A hundred unhandled exceptions with a good diagnostic is better than one caught one that destabilizes the program so it generates bad data or causes other unrelated exceptions to be thrown.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

surely you dont display the stack trace t the users. Isnt that a security risk!!!!
1

Exception management is a large subject, so I'll only touch the surface here.

From the articles ive read it states to "only handle exceptions you can recover from" What does it mean by that.

If you don't know how to recover from a specific exception, then there's not usually any point in catching it. If it's a web app or service, the web server itself will deal with the logging and recovery.

In some cases, you need to catch exceptions so that you can a generic recovery, for example by cancelling or reversing a transaction. In that case, an acceptable approach is to
catch the exception, do the generic recovery, and then throw the exception again.

If i cant handle the exception what do i do. Let it propgate back up the stack?

Yes.

If i dont handle it how can i log it and present a user friendly error message. What do most people do in web apps and web services?

The web server will log the exception. If you want to present a user-friendly error message in a web app, you can catch/log at the highest level of the stack and re-direct to your error message. Again, I would try not to catch System.Exception - instead make a list of the exceptions that your app throws, and catch just these types before presenting a message tailored to each type. As the list of exception types grows, either prevent each new exception type by changing the code, or add a new catch for that exception type.

In a web service, you can create a custom exception and add that as a node to the generic exception that the web service will provide.

In your code example, I wouldn't use try...catch unless you're expecting an exception and you know what to do with it.

How do i handle exceptions in lower tiers. Should i just let the exception bubble up the tiers.

Yes.

Improve this answer

4 Comments

thanks for that. very straight forward. If i was to catch at the highest level in a web app. What type of exception would i catch. Everywhere ive read states dont catch exceptions of type exception
@Richard: I've changed the text to answer your comment.
ok sounds good. If i want to catch a sqlexception and i want to catch it in the UI i need to add a reference to the namespace containing the exception type. Does that seem right
@Richard: I don't think that an assembly reference (to access the namespace) is a big deal. It doesn't bloat your code. I do tend to put the exception management and namespace references in a separate class to hide everything away and not pollute other classes with random namespaces.
1

Okay, this will be far too brief since it's still early in the morning here but i've been struggling with this same question so here is what I understand:

"only handle exceptions you can recover from"

My understanding here is that you get the exception to a level in your code where you can do something about it. In the case of your low level code, you would let the exception bubble back up into a layer where you could modify your 'process' to handle the exception and possibly try the process again. (I typically log the error right where it is thrown.)

Improve this answer

3 Comments

In order to extend Nitax's answer you would for example not try to handle a OutOfMemoryException that is thrown when your system runs out of memory, you would instead of crashing, attempt to save the users works and exit the application gracefully.
Generally good advice except for that last bit. If you just want to log it you should do it at the highest level possible (e.g. UI), otherwise you end up with code doing error logging scattered all over your code. If you just let them all bubble up, you can have a top-level general error handler that logs any unhandled exceptions.
@DylanSmith that is actually a good point. I have just been writing code using this method since I have different Traces defined for different areas of my code. This way the log is written to the proper Trace...

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.