Maybe We Should Keep Our Promises
medium.comMaybe you shouldn't link to the edit URL for your posts.
But on the topic, your example relies too much on pokemon code. What if you have multiple exceptions at different stage of your pipeline? What if two stages can produce the same exception type, and it's important to know which one produced it? What if you need to roll back in the event of an exception, and where the exception took place is important to doing this?
With imperative code, this is tricky. With function composition as presented in your post, it's a nightmare.
The imperative code may not be as elegant as the 'functional' solution, but in the long run, it's easier to maintain.
I was going for a clean presentation of a concept (and a gentle nudge in the direction of FP) in the article.
You raise important issues.
I would say, when you can, rewrite your code so you don't have to worry about such things.
Roll back everything under your control in the event of an error, and if there are side effects beyond your control isolate them at the end of the composition.
If two functions return the same exception, you can always wrap one of them so it returns a different one.
If a function needs it's own stand alone exception handling, do it in there.
If it really is necessary to know one could introduce some sort of monadic error handling that wraps up the results of all the functions including their place in the composition.
But really I would try to rewrite my code so that I wouldn't have to do that.