Straight line error handling

[newhoggy]

The idea with this PR is to demonstrate the use of ExceptT to enable a style of code whereby code that is logically a sequence of steps can be expressed as consecutive statements in a do block.

Error handling is achieved by attaching handlers to each statement and recovering or throwing an exception whichever is appropriate for that statement.

This PR does not change the behaviour of the code and only meant to demonstrate how it could be written.

One nice advantaging of coding in this way is that code doesn't need to get re-indented as much. If an extra step is required, it is just inserted as new lines.

With pattern matching, adding a new step could involve indenting code that follows it.

Another advantage of writing code in this style is that the error handling is always close to the code that it handles. In the code before, the error handling is often far away from the code it handles making it more difficult to reconcile the two.

This code was extracted from #4777.

[Jimbo4350]

This is a lot better than what we had before 👍 . I just want discuss the name of throwNothingM but happy to approve after.

[Jimbo4350]

Thoughts on the name throwOnNothingM? Also why the M?

[LudvikGalois]

Personally, I don't think the M adds anything here. I don't think there's a high risk of someone defining

throwNothing :: e -> Maybe a -> Either e a
throwNothing e = maybe (Left e) Right

but more importantly, I think it should be called something like throwOnNothing, since it's not throwing the Nothing. Possibly even flip the order and call it fromMaybeThrowing to avoid needing an &.

infix 1 `fromMaybeThrowing`
fromMaybeThrowing :: Monad m => Maybe a -> e -> ExceptT e m a
fromMaybeThrowing Nothing e = throwError e
fromMaybeThrowing (Just a) e = pure a

because I think that might read more nicely

  qeInMode <- toEraInMode era CardanoMode
    `fromMaybeThrowing` EraConsensusModeMismatch (AnyConsensusMode CardanoMode) (getIsCardanoEraConstraint era $ AnyCardanoEra era)

[newhoggy]

I think the & reads okay. It's a well known operator that I just read it as "and".

For example f & throwOnNothing I would read as do f and throw on nothing.

I think keeping the & is also better because it fits in with other operators like <&> that we might want to use in other contexts.

Moreover, the foo works okay for combinators that take two arguments, but in the future, it is conceivable for more combinators to be added that take more or fewer arguments.

I've renamed it to onNothingThrow because it reads well and the on prefix is likely to be common to many error handling combinators so having it first so al the ons align is more aesthetically pleasing when there are multiple handlers on the same expression.

[Jimbo4350]

Good stuff 👍

[Jimbo4350]

I'm assuming you're not using newExceptT because ExceptT is shorter?

[newhoggy]

Yeah, that's right.

[Jimbo4350]

:'(