Using this style is infectious like any other monad, so all your business will look like this. Stop reading if you are ok with this. That said, let's talk abo

Using this style is infectious like any other monad, so all your business will look like this. Stop reading if you are ok with this. That said, let's talk about validation errors vs. exceptions. Exceptions are - as the name implies - unexpected errors that unwind the stack to whoever catches them. Along the way any necessary cleanup is handled automatically. Exceptions are for cases where the error occurring is outside the scope of the business function. I/O errors come to mind, OOM etc. Now if you want to VALIDATE your data, you can do this without resorting to exception handlers or monads: You turn the outcome to your functional pipeline into data. Have validation errors? collect them in a set. Look at them after the pipeline completes. Chances are you don't want to fail on the first one. Need to do side-effects in a pipeline? Don't. Instead describe the effect with data, run them later. Need to back out early out of the pipeline? Split the pipeline at that location, handle the result, stuff it into another pipeline. Or use (shudder) a chain of interceptors that can decide if the pipeline should be continued along its happy path. If your language supports it, use pattern matching to make that decision. Note that the decision making to skip parts of the pipeline or the rest of it, is done outside your business function (which improves the chances of them being reusable because they will only be concerned with a pure data transformation and don't need to know about machinations like Maybe/Either or some such to signal things to the caller).