处理.net中的异常

Question

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.

Answer 1

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.

Answer 2

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.)

Answer 3

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.