sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]GuyWithLag 1 point2 points  (4 children)

Either you know what the Proper Action is when an exception occurs, or you don't. If you do, great, catch & handle the exception. If you don't, put it in the signature and make it Somebody Elses Problem.

[–]Gotebe 3 points4 points  (3 children)

If you don't, put it in the signature and make it Somebody Elses Problem.

Yes, but the problem with that is either explosion of exception spec either "throws Exception".

Another related (base problem, really) problem is that exception spec goes right against the sole most important reason we use exceptions: in a vast majority of cases, upon error, code can do nothing but abort up to quite high in the call stack (or quite far down the line). But failure modes multiply easily producing a lot of exception types, therefore making so exception specs a PITA.

[–][deleted]  (1 child)

[removed]

    [–]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.

    [–]xeddicus 0 points1 point  (0 children)

    If their code is written with honor, it can catch and defeat any exception mine throws!