Comparison
Railway-oriented programmingvsResult type
Railway-oriented programming
each step either continues the happy path or diverts to the failure track, and no step checks whether the last one worked.
Composing a sequence of operations that each return a result type, so a failure at any step short-circuits the rest without an explicit check between them. The two-rail metaphor is Scott Wlaschin's and it is what makes result types practical instead of tedious. The mechanism underneath is a monadic bind, which is worth knowing but not worth leading with when explaining it to a team.
Full entry →Result type
the failure came back as a return value with the reason attached, and no exception was ever thrown.
A type with a success case and a failure case carrying an error value, making a failure part of the signature. It makes the possible failures visible and forces them to be handled or explicitly passed on, where an exception is invisible and travels until something catches it. The trade is that errors have to be threaded through by hand, which is what railway-oriented programming is a technique for.
Full entry →