<story><title>Railway oriented programming</title><url>https://fsharpforfunandprofit.com/posts/recipe-part2/</url></story><parent_chain><item><author>cousin_it</author><text>Compared to exceptions, the Either approach to error handling has some big problems:&lt;p&gt;1) Good luck annotating all potential cases of divide by zero or IO error, and all callers of those.&lt;p&gt;2) Everyone must pay the runtime cost of wrapping and unwrapping on every operation, even if nothing fails.&lt;p&gt;3) The type of a function that can fail in ways A and B isn&amp;#x27;t the same as the type of a function that can fail in ways B and A.&lt;p&gt;4) Good luck getting a stack trace.&lt;p&gt;I think unchecked exceptions are better for most applications, where errors are rare and have many different types.</text></item><item><author>wldlyinaccurate</author><text>I personally find this &amp;quot;railway&amp;quot; approach (which is essentially a glorified Either) much less painful than dealing with exceptions.&lt;p&gt;Did you really find the example imperative error handling code more elegant than the railway-style function composition?</text></item><item><author>Animats</author><text>The gyrations needed for error handling in functional programming are painful.  As Rust libraries become more functional, Rust is getting more of those problems.&lt;p&gt;The problems created by not having exceptions are tougher than the problems created by having exceptions.</text></item></parent_chain><comment><author>gpderetta</author><text>4) Good luck getting a stack trace.&lt;p&gt;That&amp;#x27;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.</text></comment>
<story><title>Railway oriented programming</title><url>https://fsharpforfunandprofit.com/posts/recipe-part2/</url></story><parent_chain><item><author>cousin_it</author><text>Compared to exceptions, the Either approach to error handling has some big problems:&lt;p&gt;1) Good luck annotating all potential cases of divide by zero or IO error, and all callers of those.&lt;p&gt;2) Everyone must pay the runtime cost of wrapping and unwrapping on every operation, even if nothing fails.&lt;p&gt;3) The type of a function that can fail in ways A and B isn&amp;#x27;t the same as the type of a function that can fail in ways B and A.&lt;p&gt;4) Good luck getting a stack trace.&lt;p&gt;I think unchecked exceptions are better for most applications, where errors are rare and have many different types.</text></item><item><author>wldlyinaccurate</author><text>I personally find this &amp;quot;railway&amp;quot; approach (which is essentially a glorified Either) much less painful than dealing with exceptions.&lt;p&gt;Did you really find the example imperative error handling code more elegant than the railway-style function composition?</text></item><item><author>Animats</author><text>The gyrations needed for error handling in functional programming are painful.  As Rust libraries become more functional, Rust is getting more of those problems.&lt;p&gt;The problems created by not having exceptions are tougher than the problems created by having exceptions.</text></item></parent_chain><comment><author>exDM69</author><text>IO errors, division by zero and other truly exceptional situations are well suited for exceptions.&lt;p&gt;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.&lt;p&gt;Both styles of error handling are useful in some cases and both have their issues.</text></comment>