Exceptions in a functional language

Joel has really a bad opinion about exceptions.  He prefers to return errors as return values instead.

Now, most of this error value method / exceptions discussion seems to occur in the C++ world. In my design for my new, mostly functional programming language Babel-17, I would like to have exception handling built into the language. The reason is simply that explicit checking for error values creates messy code which is very hard to read.

So, what are the challenges of introducing exceptions into the language? A major source of problems is that Babel-17 supports lazy and concurrent evaluation. Look at the following code fragment:

val p = (10, lazy(exception "hello"))

val x = fst p

val y = try (if (snd p == 0) then 0 else 1 end) catch _ => 2

val q = (10, exception "hello")

val z = p == q

Here p is a pair that has as second element a lazy computation. Evaluation of this second element is delayed until its value is needed for the computation of y. Not clear are the answers to these questions:

• Should computing the value x throw an exception, or should x just be assigned the value 10
• Should computing the value q throw an exception, or should exceptions be allowed to be part of data structures?
• After computing  y, should p == q hold? What about before y has been computed?

Instinctively, my answers to these questions would be:

• computing x should not throw an exception, x will be assigned the value 10
• Computing q should propagate the exception and not compute a pair. Exceptions in data structures are odd, and I normally do not want that.
• q does not really exist, because its computation throws an exception. p on the other hand really exists. Also, p should not change its value depending on whether y has already been evaluated or not.

There are similar issues with concurrency:

val p = (10, concurrent(exception "hello"))

val x = fst p

One could argue that concurrency should be semantically just the identity function. Then p does not exist, because calculating p throws an exception.
One could also argue that x should evaluate to 10. This would actually be nice for the implementation of concurrency, because evaluation could then proceed in parallel.

Finally, exceptions introduce even without concurrency or laziness the question of non-determinism, if the evaluation order is not fixed:

(exception "A", exception "B")

Should this throw exception “A” or exception “B” ?

Our approach in Babel-17 is as follows: First, we introduce two new types, exceptions and errors. Exceptions can be thrown via “throw p”, where p is an arbitrary expression (note that “throw (throw p)” is legal notation, but does just the same as “throw p”). Values of type exceptions cannot be stored in data structures and propagate automatically to the top of the call stack unless they are

• caught via try/catch
• turned into errors by hitting a lazy/concurrent boundary from the inside

Values of type error on the other hand behave very much like normal data; what is special about error values is that they can be created only from exceptions or via the function constructor “error”. Otherwise error values can be passed around and stored in data structures just like any other data.

Lets revisit above sourcecode and see what this means:

val p = (10, lazy(exception "hello"))
/* semantically, p == (10, error "hello") */

val x = fst p
/* x == 10 */

val y = try (if (snd p == 0) then 0 else 1 end) catch _ => 2
/* y == 1, because error "hello" is not equal to 0 */

val q = (10, exception "hello")
/* results in an exception */

val z = p == q
/* will fail, because q is not even defined */

val p = (10, concurrent(exception "hello"))
/* Again, p is semantically the same as "(10, error "hello"). */

val q = (10, error "hello")

val z = p == q
/* z will evaluate to "true" */