Where to put Try...Catch blocks?

[salvelinus]

If sub1 calls sub2, is it better to put the try...catch block around the call in sub1, in the body of sub2, both, depends? Just wondering, thanks.

[Mike Hildner]

That's an interesting design topic, I think. I believe it's recommended that a method should handle it's own errors, at least expected errors. The calling method should not fail because the called method does.

For example sub1 calls sub2. sub2 reads and writes to some files. sub1 should not have to handle any problems that sub2 has with access modes, permissions, locking etc. sub2 should handle these and try to recover. If it can't, it can bubble up the error or throw a custom one, letting sub1 know that there was a problem with sub2. In this case, sub1 only cares that sub2 failed and try to recover, it doesn't really care why sub2 failed.

That's what I try to do in general, I'd like to see what other people think.

FWIW, although I don't do Java anymore, I really liked the design in that a calling method would not compile if it didn't catch any potential exceptions that the called method could throw. It really helped to keep things clean and made sure you wouldn't have unhandled exceptions. Wish that was in .NET. Instead, I look at the potential exceptions and make sure I catch them.

[Pirate]

Basically , Try ...Catch blocks should surround chunk of code that you suspect it errors . I mean , wrap this block around the source of error . I've never seen any error handler around called method .