failable: A 'Failable' error monad class to unify failure across monads that can fail

[ bsd3, control, exceptions, library, monad ] [ Propose Tags ]

This library contains a Failable error monad class to unify failure across monads and transformers most commonly used to implement pipelines that can fail and does so in a simple nonsense way by providing the means of signaling a computation "failure" while striving to keep the failure behaviour consistent with the actual definition of the monad/transformer. Please refer to the README file for a more elaborate description and some examples.


[Skip to Readme]
Versions [faq] 0.1.0.0, 0.1.0.1, 0.1.0.2, 0.1.0.3, 0.1.1.0, 1.0.0.0, 1.1.0.0, 1.2.0.0, 1.2.0.1, 1.2.1.0, 1.2.2.0
Change log ChangeLog.md
Dependencies base (>=4.8 && <5), mtl (==2.2.*), transformers (>=0.4.2 && <0.6) [details]
License BSD-3-Clause
Copyright 2019 Erick Gonzalez
Author Erick Gonzalez
Maintainer erick@codemonkeylabs.de
Revised Revision 1 made by erick at Wed Jan 30 15:37:03 UTC 2019
Category control, exceptions, monad
Bug tracker https://gitlab.com/codemonkeylabs/failable/issues
Source repo head: git clone https://gitlab.com/codemonkeylabs/failable
Uploaded by erick at Sat Jan 12 11:17:28 UTC 2019
Distributions NixOS:1.2.2.0, Stackage:1.2.2.0
Downloads 859 total (138 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Hackage Matrix CI
Docs available [build log]
Last success reported on 2019-01-12 [all 1 reports]

Modules

[Index] [Quick Jump]

Downloads

Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.

Maintainer's Corner

For package maintainers and hackage trustees


Readme for failable-0.1.0.1

[back to package description]

failable

Yet another "error" handling monad (class)

This library provides a 'Failable' error monad class to unify failure across monads and transformers most commonly used to implement pipelines that can fail.

But.. don't we have 'MonadFail', 'MonadThrow', 'MonadError',.. and the true haskeller should be using 'Alternative' anyway!

I am sure a lot of ink has been spilled in forums and around water coolers all around the world, debating the merits and fallacies of one approach or the other. The reason for this package is not to participate in this discussion but rather to provide a simple nonsense means of signaling a computation "failure" in those monads that provide the inherent means to do so, and to do it in a consistent manner

Usage


data FooError = NotImplemented deriving (Typeable, Show)

instance Exception FooError

foo :: (Failable m) => m Int
foo = failure NotImplemented

Now, if one called foo in a Maybe monad:

> foo :: Maybe Int
> Nothing

the failure is then conveyed by returning Nothing as per definition of the Maybe monad. Now in the case of the Either SomeException monad:

> foo :: Either SomeException Int
> Left NotImplemented

but what if we are working in the IO monad?

> foo :: IO Int
> * * * Exception: NotImplemented

In this case, the failure can only be conveyed by throwing an IO exception.

Now, the point where Failable diverges from say MonadThrow for example is when it comes to monad transformers. For example:

> runMaybeT foo :: IO (Maybe Int)

Would throw an Exception: NotImplemented if it was implemented in a MonadThrow context. Since the reason d'etre for the runMaybeT is to provide the underlying monad (transformer) with Maybe like behaviour, i.e. have Nothing be returned in case of aborting the Maybe pipeline so to speak, then throwing an exception defeats IMHO the purpose of using MaybeT in the first place. So, in the case of Failable:

> runMaybeT foo :: IO (Maybe Int)
> Nothing

And the same thing applies to runExceptT etc.