I'm not a fan of exceptions but the alternatives that are usually suggested are worse reinventions of exceptions.
Error handling is really not that hard to analyse: In case of an error you can only do a couple of different things: * Let it "bubble up" the call stack. * Retry the operation. * Report/discard and continue with the next instruction whatever that means. * Trap/quit/die. Arguably that is just a shortcut for bubbling up the call stack and let the OS's "exception handler" deal with it. * Turn it into a regular value, no Option[T] or Either[T, E] do **not** count. <\-- I'm personally in favour of this, but nobody agrees with me and in theory it can make errors harder to diagnose. What exceptions do is they claim "let it bubble up is what you want in over 90% of all the cases out there so we make this the implicit, fast, default model of operation". To refute exceptions you need to come up with a decent statistic that proves this wrong or you need to argue that "implicit is bad". "Implicit is bad" ignores too much the point of using computers in the first place in my opinion which leaves us with (b) statistics. So bring them on, I say.
