
Maybe We Should Keep Our Promises - rmoskal
https://medium.com/p/cb2f256f9c73/edit
======
the_hoser
Maybe 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.

~~~
rmoskal
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.

