How should I deal with exceptions?

Question

I have three possible choices that I see:
(1) Deal with them in an exception handler class. Use try/catch/throw in the class. Have throw call a method in the exception handler class.
(2) Use try/catch/throw and handle the exception in the same class where the exception occurs.
(3) Use throws and deal with the exceptions in the mediator class. The mediator class allows for communication between my FileHandler class, my DBHandler class, my UIClass, and any future classes.
Note that for each exception, I want to call a method in the UI class that displays a message to the user about the error so it can be debugged and a method in some class to write the error to an error log text file.

Answer 1

Handling
can mean as little as logging the error.I'm gonna have to go ahead and disagree with youthere, %.
Disagree with me? This cannot be tolerated! 8)Watch it, lest yet get yer ass smote.
Except for where you're intentionally
smothering exceptions in finally blocks, or maybe
just recording an InterruptedException, justlogging
it is little better than smothering it. So what about unchecked exceptions? Are these .NET
demon spawn?I let unchecked exceptions bubble up. I'd expect an appserver to catch and log them, so that a bug in one app doesn't cause the whole server to barf. But other than that kind of situation, these are exceptions that you usually shouldn't try to handle.
>
I'm curious, since this thread is so much about
handling exceptions. What do people do besides
report them? If you get a SQL exception, what
recovery actions are you taking? Anything that I'm
missing?Usually it just bubbles up, or it's a wrapped in a more appropriate or layer-specific exception and rethrown. Sometimes there might be a retry, but usually the exception bubbles up to the higher layers and gets presented to the user as something like, "Could not connect. Retry?" What I hate to see is this:
try {
    // get stuff from the DB
catch (SQLExeption exc) {
    // log it
// Continue here (where "here" may be the calling method)
// with no idea that anything went wong.If you do that, you might as well not have an exception mechanism. Just go back to return codes and don't bother checking them.