Exception handling - more

Question

Okay, new day new questions.
What's better?
method ...() {
try {
doMethod1();
catch (exception) {
// handle error
try {
doMethod2();
catch (exception) {
// handle error
}or
method()...{
try {
doMethod1();
doMethod2();
catch (exception) {
// handle exception
}The question is readability and program flow. If you wrap up a chunk of a code block which contains methods that throw exceptions as well as those that don't, when you're reading back through it it's hard to know which methods throw exceptions and which don't. It's hard to see the flow of the program just by looking at the code.
But if you wrap up every method in a try/catch that can throw an exception you make it just as hard to see the program flow since you're dealing with multiple exceptions where each catch handles the error in much the same way. Instead of breaking out of the method at one place you could now be breaking out at several.
Comments? Suggestions?

Answer 1

There's one more: don't catch anything and declare your method to throw them, that way the calling method gets thrown an exception containing not only a full stack trace but also a (supposedly) descriptive message.
Of course we know that that is not always the case.
I think the "best" way depends on circumstances. I was asked at a job interview, "How do you decide whether to catch and exceptions in a method or to have them throw 'em on up?". My answer was to stammer around a bit, then reply very cleverly with "It depends."
HaHa, but I think it's true. It depends on the kind of program, the purpose of the method, and the potential uses of the method. (ps. the interviewer is now my boss, so maybe I was right?)
A story from my past life: there was once a class/method, originally never intended to be used outside of its package and the single use they had in mind when they designed it. Unfortunately, time proved that this package has some useful stuff and it grew into kindof an widely used API within the company. However the class/method to which I refer was responsible for open a Socket connection (from an IP address string and string port number) to a device and communicating some bytes back and forth to initialize the device (can you count how many checked much less unchecked things can come out of that before you even do any validity checking???). However, this constructor caught all of its exceptions and handled them by writing to some logging system that existed only in the original system). Therefore, years later when I was writing a GUI that used this class, my GUI had no way of knowing if anything was wrong, much less what actually was wrong.
The moral of the story is that I have come to believe in letting exceptions float up as high as reasonable, because you never know. (Of course I don't always practice this flawlessly.)
/Mel