Comment by lincolnq | Hacker News Reader

Comment by lincolnq | Hacker News Reader

Fundamentally I want to be able to ask my programming language "what exceptions might propagate to here?" Having this ability allows me to make stronger claims that my program is correct, because then I can say that the only exceptions which can propagate to that point are of a type I have decided not to handle (like the filesystem being disconnected) and this can be a strong safety property.

I think Java has ruined checked exceptions for the rest of us, because this article makes good points and successfully knocks down Java's exception system. I don't think this invalidates the concept of checking one's exceptions, though!

What would I do instead? Since it's always the prerogative of the receiver of a possible exception to rethrow it uncheckedly, then why not allow the type system to promote (/demote) a checked exception to unchecked at the catchpoint, without requiring an actual catch block? Some system like that could reduce the syntax clutter which is the root of the author's beef.

Clojure catches all exceptions from Java methods, rethrowing them as runtime exceptions. In other words, it gets rid of checked exceptions. (It has to, if you think about it.)

No type system support... but no catch block, either.

It's possible to analyze programs to find out what exceptions can be delivered to a particular point in the program. As an example, here is such an analyzer for OCaml code:

http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm

"Ocamlexc is a framework designed to statically analyze Objective Caml programs in order to discover potentially raised and uncaught exceptions. Such exceptions are harmful because they cause the immediate end of the running program. This tool can hence be seen as a static debugging tools, adding more safety to the already powerful static and strong typing system that makes ML programs so robust."

You could use RuntimeException as a superclass for your exceptions, or wrap checked exceptions in a RuntimeException. I'll often rethrow exceptions this way when I have to deal with something horribly wrong (like I/O or UI meltdown, etc.) in a place where I have to deal with the checked exception.. This is handled gracefully in the Eclipse workbench as a popup though, YMMV.

I would only recommend this as a last ditch effort to appease the Java compiler though, not an acceptable way to handle a common failure mode.

As a side note, does anyone else find the pattern (well, I would say headache) of dealing with checked exceptions similar to working with the IO monad in Haskell?

I often explain monads to laypeople as "It's a way to abstract away extra information that's passed through the computation, and define arbitrary ways to handle that information." One of the possible types of "extra information" that may be attached are the types of exceptions thrown: see the Error monad.

And yeah, monads have most of the same problems that checked exceptions do. Each action in the monad must have the same type; you can't just ignore one of those bits of extra information and declare that it doesn't matter in this context. For example, if your complicated algorithm writes to a log file, you probably don't care in the rest of the program and could just as easily treat it as pure. But the type system won't let you, unless you fall back on cheats like unsafePerformIO.

I dunno really what the right answer for this is, but I really like the Erlang philosophy toward errors. "Let it crash, then do something simpler." Instead of trying to enumerate all the ways your program can fail, it just assumes that you will fail sometimes, so you ought to try multiple ways to succeed instead. That requires quite a paradigm shift from the way programmers normally think about programming, though.

Reply on news.ycombinator.com