[Haskell-cafe] Error handling package

[Michael Snoyman]

(Sorry, accidently took off cafe.)

On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Mon, 19 Oct 2009, Michael Snoyman wrote:
>
>  Does the explicit-exception package provide what you need?
>>
>> http://hackage.haskell.org/package/explicit-exception
>>
>>
>> I don't think so, but correct me if I'm wrong. I want to make it easy to
>> chain together
>> computations which could fail in different ways. For example, something
>> like this:
>>
>> attemptReadInt :: String -> Attempt Int
>> attemptLookup :: String -> [(String, String)] -> Attempt String
>> attemptLookupInt :: String -> [(String, String)] -> Attempt Int
>> attemptLookupInt k m = attemptLookup k m >>= attemptReadInt
>>
>> Now, in the explicit-exception package, I could- in this simple example-
>> define
>> something like:
>>
>> data MyErrors = KeyNotFound | InvalidInt
>>
>
>
> type Attempt = Exceptional MyErrors
>
True; that's what I meant by I could do this in my simple example.

>
>
>  But this solution would not scale.
>>
>
> You want to add other exceptions? The idea of my package is to make
> exceptions explicit in the type. Otherwise you would use
> extensible-exceptions. Or you could define MyErrors using an existential
> type.


Which is my point. I'm trying to provide a package for non-explicit
exceptions. To compare to other programming languages, I think your package
is providing the equivalent of Java checked exceptions, while mine is
providing (safe) unchecked exceptions. I say safe because you still need to
explicitly decide to turn an Attempt into a possible runtime exception which
will bring down your program.

Defining MyErrors using an existential type would essentially recreate the
entire attempt package; I don't see that purpose in everyone wanted
unchecked exceptions needing to reinvent the wheel in non-compatible ways.
If multiple libraries use attempt, they can easily have their
possible-error-returning functions chain together safely.


>
>
>  Additionally, there's two immediate features I think I would miss from my
>> package:
>>
>> 1) fail works properly, so an Attempt would be a valid monad response from
>> people who
>> use that function.
>>
>
> As far as I understand, 'fail' is used/abused for reporting failed pattern
> matches in do notation. If a failed pattern match indicates a programming
> error, it should be a really error, and not something that must be handled
> at run-time.
>

That's a lot of very debateable statements you just made. It might be that
it's strongly encouraged to only use fail for failed pattern matching, but
in practice you could use it for any monadic failure. Also, there's nothing
stopping a user from re-throwing pattern match exceptions received in an
Attempt.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091018/1f49a9d3/attachment.html