[wvenable]

> By definition, for you to handle it somewhere requires knowing the entry point to the call chain that may throw exception(s) that you decide to handle. At this point, you're wrapping some method invocation with a catch block, are you not?

I think you're still missing the point and maybe I'm not explaining it well. For you to handle an exception, you don't need to know where something may throw an exception. You just need to know where you can handle the error. For example, if I'm iterating a data set and performing a web service call per iteration then I'm more than likely going to put my exception handling inside that iteration around that service call. My recovery is more than likely going to be retrying the service call a few times and then give up and iterate to the next item. Perhaps enough overall failures will terminate the whole loop.

So yes, at some point I will be wrapping some method invocation with a catch block. Does that method throw an exception? Yes. All methods throw exceptions.

> What if there are several sockets involved in the operation and you want to reconnect just the failing one, for example?

Obviously, you do need to put the exception handling code where you can reasonably handle the error. Which is just restating my point. If your code generates several sockets and performs operations on them then the error handling should be connected to those operations. So again the decision about where to put the error handling is not based on which methods throw (they all throw) it's about where it makes the most sense to handle it.

I believe exception handling should build up from the generic to the more specific as needed. If you have to handle every single exception at every call site then that's building it down from the most specific case. Java forces you to do this and it's almost always a waste of time and mental effort. It also makes iterative design difficult. Most first versions of my applications have just one single handler that logs everything and terminates. Many times that's good enough. But where it's not good enough, the next version can be easily improved with specifically targeted exception handling sprinkled in as needed.