Re: [Haskell-cafe] Error handling package

20 Oct 2009

      On Tue, Oct 20, 2009 at 5:17 PM, Nicolas Pouillard <
nicolas.pouillard@gmail.com> wrote:
...
On Tue, Oct 20, 2009 at 3:12 PM, Michael Snoyman 
wrote:
...
On Tue, Oct 20, 2009 at 11:04 AM, Nicolas Pouillard
 wrote:
...
On Sun, Oct 18, 2009 at 9:45 PM, Michael Snoyman 
wrote:
...
While working on the next release of data-object, I wanted to
represent
[...]
...
...
About the name Attempt, I think that 'Outcome' would be a better name.
The problem with a name like "Outcome" is that it doesn't really imply
the
possibility of failure, simply that we are wrapping of the result for
some
reason.
I don't see why, the outcome of an action could be either a success or
a failure.
Even if the only *desired* outcome is success.
I think I'm going to stick with Attempt. The only other point that came to
me is it's nicer to have a function called "attempt" than "outcome" IMO.
...
...
...
...
2) Are there any other FromAttempt instances I should provide out of
the
box?
None that I see.
...
3) I was considering adding specialized versions of the fromAttempt
function, ie ioFromAttempt, maybeFromAttempt. Thoughts?
It is a bit long to spell.
True, but it can be more convenient than giving explicit type signatures.
The main reason this might come up would be regarding the (Either String)
and (Either SomeException) instances.
...
...
4) Should I follow the naming scheme attemptJoin, attemptLookup, etc,
or
...
...
just call the functions join, lookup and force people to import the
module
qualified?
A nice alternative would be to make a Data.Attempt.Extra (or a better
name) which
would be imported qualified.
I like. The only other name I can think of right now is
Data.Attempt.Helper,
but that's just painting the bike shed.
I also prefer Helper.
Done. Not full-featured yet, but does provide a nice core.
...
...
...
...
5) Any other suggestions for attempt functions? I've considered
head/tail/etc.
Why not, maybe the 'safe' package should be of some inspiration.
Once they're all in their own module, I don't see a problem adding as
many
as possible.
[...]
...
...
attempt :: (forall e. Exception e -> b) -> (a -> b) -> Attempt a -> b
I was trying to more model it after fromMaybe, but instead just ended up
with something ugly. I'm going to rewrite attempt using this type
signature
and then add fromAttempt as well.
Fine, fromAttempt should follow fromMaybe
fromAttempt :: (forall e. Exception e -> a) -> Attempt a -> a
fromAttempt f a = attempt f id a
And of course I now realize this name will conflict with the FromAttempt
typeclass ;). I think we'll be safe leaving this function out, considering
how trivial it is to implement in terms of attempt.

Also, I've added a monad transformer to the github repo. I've tried it out
in some local code I have, and it *really* cleans up the error handling.

Michael