Railway Oriented Programming
The author followed up this post with another one a few years later titled &quot;Against Railway Oriented Programming&quot;:<p><a href="https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;posts&#x2F;against-railway-oriented-programming&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;posts&#x2F;against-railway-orie...</a><p>Railway-oriented programming is an interesting concept and it does have its use cases, but it does need to come with a massive health warning. I&#x27;ve often seen it used in practice to reinvent exception handling badly, and this is something I consider particularly ill advised because exceptions, when understood and used correctly, provide a much cleaner and more effective way of handling error conditions in most cases.<p>The thing about exceptions is that in most cases, they make the safe option the default. An error condition is an indication that your code can not do what its specification says that it does, and in that case you need to stop what you are doing, because to continue regardless means that your code will be operating under assumptions that are incorrect, potentially corrupting data. Error conditions can happen for a wide variety of reasons, many of which you do not anticipate and can not plan for, and in those cases the only safe option is to clean up if necessary and then propagate the error up to the caller. Exceptions do this automatically for you by default (you need to explicitly override it with a try&#x2F;catch block) but alternative approaches, such as railway oriented programming, require you to add in a whole lot of extra boilerplate code that is easy to forget and easy to get wrong. If you can&#x27;t handle the error condition on the way up the call stack, you would then log it at the top level and report a generic error to the user.<p>Having said that I see two particular use cases for this kind of technique. The first is situations where you need to handle specific, well defined and anticipated errors right at the point at which they occur. Validation is one example that comes to mind; another example is where you are trying to fetch a file or database record that does not exist. The second is situations where exception handling is not available for whatever reason. Asynchronous code using promises (for example with jQuery) are pretty much an exact implementation of railway oriented programming, but since modern JavaScript now has async&#x2F;await, we can now use exception handling in these scenarios.