|
|
|
|
|
|
by Lio
823 days ago
|
|
|
It's always worth reading Against Railway-Oriented Programming[1] before you commit to using it. Personally I've dealt with enough Trailblazer code now that for business logic I think I'd much rather work with a simple ruby class with a procedural interface. I like the use of a Result object but not at the expense of exception handling or bloated stacktraces full of library code. Being lightweight, easy to debug and upgrade is underrated IMHO. Having said all that, I still think this is a really interesting article and great food for thought depending the usecase. 1. https://fsharpforfunandprofit.com/posts/against-railway-orie... |
|
|
I would add that the tagline says "when used thoughtlessly".
For example, I agree that using Result objects to reinvent exceptions is a bad idea. There's a reason they're called "exceptions". Error results should only be used for domain-level errors. ie. things that _your expect_ to go wrong in the domain.
Also note that in my article I use continue/halt, not Ok/Error. At the library level it's just a way to compose functions together with a mechanism to halt processing. Whether something halted execution because it was an error, or any other reason (ex. caching), is up to your app's semantics.