Hacker News Reader

Comment by cousin_it | Hacker News Reader

Compared to exceptions, the Either approach to error handling has some big problems:

1) Good luck annotating all potential cases of divide by zero or IO error, and all callers of those.

2) Everyone must pay the runtime cost of wrapping and unwrapping on every operation, even if nothing fails.

3) The type of a function that can fail in ways A and B isn't the same as the type of a function that can fail in ways B and A.

4) Good luck getting a stack trace.

I think unchecked exceptions are better for most applications, where errors are rare and have many different types.

View on HN

4) Good luck getting a stack trace.

That's a great point. At the end of the day, Either and (checked) exceptions are equivalent from a semantic point of view, but having exceptions being an explicit part of the language means much better support for tooling and debugging.

Nothing prevents the system to add a stack trace on the Error branch of an Either. It's just that some evaluation strategies [lazy] that are usually associated with functionally programming [Haskell] provide unusual reduction traces. An eagerly evaluated expression would add the usual stack traces.

It is not just stack traces. If an exception is not handled, the debugger will break at the frame that trowing the exception (at leat on sane implementations that do two phase unwind), while with either (and error codes) all state useful for debugging will have been destroyed.

1) This is kind of invariant failures (logic errors that should never happens) and handled by panics in the same way as C++ exceptions. 2) In most cases Result<T, E>/Optional is returned from a heavyweight operation (I/O, dictionary lookup, etc) compared to an easily predicted error checking branch. 3) Probably this is problems of a type system or design, not an error handling strategy. 4) Good luck of getting a stack trace of re-thrown (propogated) exception in C++.

Exceptions are not too bad, but they are very often misused.

> Exceptions are not too bad, but they are very often misused.

This! The worst is when people start using them to control the flow of business logic. I hate that.

Just wait until the same people get hold of monads to implement their business logic.

What actually is so bad about doing this?

I'm a data scientist, not the software engineer, so forgive me if this is something you all learned in CS 101.

You know how GOTO is real bad? Well, using exceptions for flow control* is basically a thinly disguised GOTO.

Also, constructing an exception object, with the full stacktrace etc., is a pretty heavy operation and can cause big performance issues. But it's mostly the first thing.

* Which is an important distinction. Flow control exception are recognisable because you intentionally throw an exception and expect it to be caught by a particular catcher to process it in a particular way - much like a GOTO, and with all its fragility. In the proper usage of exceptions, when you throw an exception you don't care which line of code catches it and when you catch an exception you don't care which line of code threw it.

Believe it or not, I was just working on a script this weekend that was becoming a nightmare to debug. And when I realized that I had been lazily using exceptions as control flow, this really hit home.

IO errors, division by zero and other truly exceptional situations are well suited for exceptions.

Validation cases like the examples on the article are not exceptional and the failure cases must be handled properly. In this case it makes sense to use an Either -like solution where the compiler will warn if there are unhandled cases.

Both styles of error handling are useful in some cases and both have their issues.

3) and 4) are essentially subclasses of 1) and to solve 1) one needs a typesystem like in Koka or PureScript where code is polymorphic regarding effects so introducing new one without breaking existing code is possible. PureScript uses that to precisely model JS exceptions.

As for 2) the exceptions are not zero-costs even with modern implementations and profile-driven optimizing compiler makes the runtime cost of wrapping/unwrapping low.

C++ exception can be "zero cost" in the non exceptional path (for example http://llvm.org/docs/ExceptionHandling.html#itanium-abi-zero...)

Presence of exceptions still prevents some optimizations that the compiler can do otherwise like omitting frame pointer etc.

Did you even read the article? For the points 1 and 4 F# has exceptions that are handled seamlessly with this technique using a simple function in the chain, as clearly showed in the article. For point 2 you are just using a different operator from the normal composition one. I don't understand your point 3.

I've read the article and don't completely understand your comment.

For point 1, if you want to use the railway approach instead of exceptions, you must annotate all functions in the chain.

For point 2, I was talking about the runtime cost.

For point 3, Result<Result<Foo,A>,B> isn't the same type as Result<Result<Foo,B>,A>. People in the Haskell world acknowledge that it's a big problem ("monads don't compose"), hence all the research on monad transformers and extensible effects etc.

For point 4, if your function is the lowest in the call stack and decides to report an error using the railway approach, you don't get a stack trace.

For 1 and 4, is not for runtime exceptions (div by 0, out of memory, etc) that you need to bubble up to the top, is for "logic"/checked exceptions where you want to use code to deal with the failure case. For 3, that totally defeats the purpose, the whole point is to have a single error type (it can capture the details of the error anyway) then you can have

  Foo -> Result<Foo1,Error>
  Foo1 -> Result<Foo2,Error>
  Foo2 -> Result<Foo3,Error>

And use bind to compose them easily.

I think the confusing part is the word "exception" as it mixes concepts.

Reply on news.ycombinator.com