4 ms·

I think you may like Monads for exactly the reasons you described though, I wouldn't focus too much on this particular sentence. Monads for error handling are

I think you may like Monads for exactly the reasons you described though, I wouldn't focus too much on this particular sentence. Monads for error handling are very similar to exceptions - they let you write your code in terms of only the happy path, but letting each step fail the entire computation if something unintended happens (with a relevant error). They also have some advantages if you like to be explicit about the "dark path". 1) In traditional imperative programming you have to make a choice between errors as exceptions (implicit) and errors as return values (explicit) - monads let you do both at the same time in a sense --- whether you get implicit or explicit behaviour depends on how you "glue" computations together. 2) Monads are more explicit about when a dark path exists in the sense that they will have a different type signature and often different syntax (at least in haskell/c#/scala and other languages that support explicit monad-based notation) I'm not a huge fan of Monads for error handling in languages like Javascript without explicit support for them though, mostly as they just don't read very well.

ljm 7y ago
I’ve found exceptions fairly cumbersome to work with in ‘enterprise class’ software. Although I wonder if enterprise class software is cumbersome in and of itself, no matter how you write it. Even in Ruby, handling the correct exception basically requires you to know that one is thrown, and then to know what kind of exception is thrown. So you sort of have to TDD your way through it. Or you just rescue every exception ever and hope for the best. You can still make it quite nice but I don’t think our modern brand of OOP has the intuitive approach here: Haskell’s Either, Rust’s Result, Go’s facsimile of that with multiple return values, and Erlang’s approach to just letting things blow up are far easier for me to build a mental model around. There’s no guesswork: you don’t acknowledge the possibility of an error (let alone handle it), your build fails. Even without them, you also have Maybe or Option to get rid of the accidental null values floating up the stack.

ljm 7y ago

I’ve found exceptions fairly cumbersome to work with in ‘enterprise class’ software. Although I wonder if enterprise class software is cumbersome in and of itself, no matter how you write it. Even in Ruby, handling the correct exception basically requires you to know that one is thrown, and then to know what kind of exception is thrown. So you sort of have to TDD your way through it. Or you just rescue every exception ever and hope for the best. You can still make it quite nice but I don’t think our modern brand of OOP has the intuitive approach here: Haskell’s Either, Rust’s Result, Go’s facsimile of that with multiple return values, and Erlang’s approach to just letting things blow up are far easier for me to build a mental model around. There’s no guesswork: you don’t acknowledge the possibility of an error (let alone handle it), your build fails. Even without them, you also have Maybe or Option to get rid of the accidental null values floating up the stack.