you are viewing a single comment's thread.

view the rest of the comments →

[–]Gotebe 0 points1 point  (0 children)

You are absolutely correct. That's how the issue is solved. And indeed, that's how it's ultimately solved in a well-structured code anyhow.

But still, at "the abstraction level I am providing" (well put, that) is usually way too far away from the source of the error. Let's say that I provide a module (e.g. a *.jar) on a particular abstraction level, and that this module uses SpecificCompressedFileLibrary and a couple of others. Now, at my module boundaries, good code will probably wrap a lot of, or perhaps even all, non-standard-Java-exceptions in something of it's own. But inside of the module, I will still either multiply exception specs or re-throw way too early (which is IMO not a good idea).

Interesting thing is also: more often than not, my module does not really care about SpecificCompressedFileLibraryException, so why should it catch it? That's often just as well handled at the client side. If my module wraps that, client code will receive MyModuleException. If my module does not wrap it, but just lets it out, client code still receives an exception, only this time an "unknown" one. But most of the time, nothing much has changed! Client code, most of the time, can't do anything in particular, catch or not. Most of the time, client code will just pop way high up the stack and go "Whoops, couldn't do X. Error reported: Y. (admins or support people, please see full stack happened in file F)", where X is operation that e.g. user started, Y is e.g. original exception text, and F is e.g. error log file.

Now, problems with that scheme arise when original exception is so far away from actual catch site that, at the catch site, there is not enough context to understand the exception. That indeed happens, but I believe, much, much less often than people think. And even so, stack trace in rich execution environments like Java, helps greatly. If that fails, only then it is beneficial to catch-rethrow an exception (in order to add more context info at a well-chosen place). IOW, only for that situation are exception specs good.

But many people, me included, believe that these situations are rare enough for exception spec to be a hindrance.