Exceptions are often a better way to handle errors than returning them as values. We argue that traditional exceptions provide better user and developer experience, and show that they even result in faster execution.
In Maybe monadic, its monadic bind will automatically resolves any failed computation, and don’t need explicit checking.
for example, the code in Haskell looks something like the following:
fib: Int -> Int -> Maybe Int
fib depth idx =
do
guard (depth < 10)
n1 <- fib (depth - 1) (idx - 1)
n2 <- fib (depth - 1) (idx - 2)
return (n1 + n2)
Haskell type class system automatically figures out this is a maybe monad, and check for error accordingly.
Notice, unlike the C code the author provide, this haskell code will exit immediately when n1 failed and never compute n2, similar to the behavior of the exception code. Thus I believe his point about performance is at least unjustified, if not wrong.
Another interesting fact about this code is that there is nothing that is built into the compiler/interpretor (except the do expression, which is just a minor syntactical sugar), you don’t need to design special semantics for raise and catch. Everything here, guard, return and the definition of Maybe monad (which is in charge of propagating errors) is defibed by the user using normal functions, no metaprogramming involved.
Wouldn’t effect systems still be considered exceptions, but handled differently?
Yes, unlike monad, the error is propagated by the compiler/interpretor, instead of user defined. But unlike implicit effect, explicit effect (algebraic effect, throwable, etc.) makes it clear how the code can go wrong.
Although explicit error is more clear in general, there are special cases where explicit effect is undesirable. One such example is effect pollution, where low level effect that is unlikely to cause impure behavior is necessarily propgated through the call stack. Making the code more verbose and harder to handle.
In Maybe monadic, its monadic bind will automatically resolves any failed computation, and don’t need explicit checking.
for example, the code in Haskell looks something like the following:
fib: Int -> Int -> Maybe Int fib depth idx = do guard (depth < 10) n1 <- fib (depth - 1) (idx - 1) n2 <- fib (depth - 1) (idx - 2) return (n1 + n2)Haskell type class system automatically figures out this is a maybe monad, and check for error accordingly.
Notice, unlike the C code the author provide, this haskell code will exit immediately when
n1failed and never computen2, similar to the behavior of the exception code. Thus I believe his point about performance is at least unjustified, if not wrong.Another interesting fact about this code is that there is nothing that is built into the compiler/interpretor (except the
doexpression, which is just a minor syntactical sugar), you don’t need to design special semantics for raise and catch. Everything here,guard,returnand the definition ofMaybemonad (which is in charge of propagating errors) is defibed by the user using normal functions, no metaprogramming involved.Yes, unlike monad, the error is propagated by the compiler/interpretor, instead of user defined. But unlike implicit effect, explicit effect (algebraic effect, throwable, etc.) makes it clear how the code can go wrong.
Although explicit error is more clear in general, there are special cases where explicit effect is undesirable. One such example is effect pollution, where low level effect that is unlikely to cause impure behavior is necessarily propgated through the call stack. Making the code more verbose and harder to handle.