Uses

Posted Mar 31, 2012 7:56 UTC (Sat) by fdr (subscriber, #57064) [Link]

Posted Mar 31, 2012 22:52 UTC (Sat) by cmccabe (guest, #60281) [Link]

Unchecked exceptions remove information from the type system, which makes the system less robust, for the same reason using void* and not enforcing invariants does. C++, Python, and many other languages ONLY have unchecked exceptions. In many cases, it's difficult even to get information about what exceptions can be thrown, let alone what to do about them, without reading the entire source code of the function you're calling and all the functions it calls. I've been in this situation before, and it's not pretty. For me at least, this kind of "error handling" is really "error ignoring" since the likelihood that maintenance programmers will know all that stuff approaches zero as time goes on.

Checked exceptions, on the other hand, tend to be just as verbose (and sometimes more verbose) than simple if-then error handling. For example:

try {
  if (is_set(ctx, 'debug_mode') && is_set(ctx,'show_log'))
    do_something();
} catch (IOException e) {
  throw new BlahFailedException("blah failed!  Error: " +
    e.getMessage());
} catch (DoSomethingException e) {
  throw new BlahFailedException("do_something failed!  Error: " +
    e.getMessage());
}

And if you think it's always possible to change your function signature to declare all the checked exceptions you want to throw, think again. For example, if you are implementing an interface like SAXParser or something, you don't get that kind of choice. You'll have to catch and translate every checked exception into either a RuntimeException (which ruins type-safety) or a SAXParseException (which is misleading and verbose to implement).

A final comment. If you design the system such that there are a lot of corner cases are tricky situations, then yes, your code will be tricky. On the other hand, if you design the system such that it's simple, you won't feel the need for complexity. For example, you could load the entire configuration at once and keep it in memory, eliminating the need to handle the "file not found" error condition that you're so worried about. Exceptions don't reduce the complexity of code. At best, they just sweep it under the rug. And that's not a good thing, for anyone concerned.

Another note. In its newest language, Ceylon, Red Hat is getting rid of checked exceptions. Google coding standards for C++ dictate no use of exceptions-- ever. I think the way Go handles exceptions is the right way.

Posted Mar 30, 2012 22:01 UTC (Fri) by khim (subscriber, #9252) [Link]

On the other hand, exceptions tend to work nice when you have to repeatedly call library functions that almost always work as intended (that is, errors are really exceptional). In that case you can save a lot of error checking and write simpler code.

Yup. And as added bonus it'll guarantee your future employment when you'll find and fix dozens of security bugs and DOS cases.

4. Program defensively, specially when holding resources (open files, locks, connections, memory). Expect unexpected exceptions everywhere. Your code will probably have a longer and more interesting live than you expect.

This is what makes exceptions pointless. It's hard enough to find programmers which can correctly programs the common case. Someone who can correctly program all the exceptional codepaths will be usually too expensive. And will still miss some cases.

This is where fork(2) solution saves your beacon: sure, you still need to somehow handle cases where some shared resources (such as pipe or shared memory) misbehaves because other process died but most of the heavy lifting will be done by OS without your direct involvement: sockets will be freed, files will be closed and removed (you do remove temporary files right after open(2) call, because you need to handle poweroff case, right?), etc.

Go is trying to create something like this in a single process - but I'm not 100% sure how well it'll work.