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.
I don’t know the answer to your question, but I think that what is needed is just a bit of syntactic sugar, e.g. Rust has ? for returning compatible errors without looking into them. That seems to be powered by Try trait, that may be a monad, but I am not fluent enough to check if it formally is.
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.
Can you please demonstrate how async workflows and monads resolve this issue?
Wouldn’t effect systems still be considered exceptions, but handled differently?
I don’t know the answer to your question, but I think that what is needed is just a bit of syntactic sugar, e.g. Rust has
?for returning compatible errors without looking into them. That seems to be powered byTrytrait, that may be a monad, but I am not fluent enough to check if it formally is.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.