Proposal: Add exception info

[Edward Kmett]

I have to confess that I don't really like this proposal in its current
form.

We use a little bit of Typeable magic in SomeException to model an open sum
type. It is more or less "just enough" to get us an open set of exceptions
on which we can match.

That gives us a nice case analysis construction, we can basically reason
type by type and ask if SomeException _is_ a particular data type without
losing any information.

Theoretically it means I can give you a nice prism or case handler for it,
match on it, rethrow it and nothing is lost.

This proposal gives up a very nice property in exchange for an ad hoc
ability to decorate exceptions with anything we want. This strikes me as a
short term gain in exchange for giving up a lot of future reasoning power.
What is your exception decorated with? Go spend O(n) time rummaging through
the list of attached decorations to find out! =/

I'm not offering a concrete worked solution, but there are many other
points in this design space. e.g. having a class to let you attach the
particular information you want to particular exceptions, having an
exception type you can throw with a stack intact that acts as an exception
transformer, etc.

None of those require us to give up the simplicity of the open exceptions,
but those first two obvious directions have obvious drawbacks, hence why
"I'm not offering a concrete worked solution."

Davean's variant narrows the focus down considerably. Limiting it to just
the issue at hand, rather than trying to construct a solution to all sorts
of problems we haven't even thought of yet. I could get behind something
with a more retrenched scope, like that.

That said, I'd very much rather err on the side of doing nothing rather
than do the wrong thing here.

We'll be stuck with it for a long time.

-Edward

On Sun, Apr 26, 2015 at 4:26 PM, Michael Sloan <mgsloan at gmail.com> wrote:

> Right, we have a choice between making a breaking change towards a more
> standard API, or using a rather new language extension (bidirectional
> pattern synonyms) to avoid breakage.
>
> On Thu, Apr 23, 2015 at 6:30 AM, Greg Weber <greg at gregweber.info> wrote:
>
>>
>>
>> On Tue, Apr 21, 2015 at 1:55 PM, Michael Sloan <mgsloan at gmail.com> wrote:
>>
>>>
>>> On Tue, Apr 21, 2015 at 8:23 AM, Greg Weber <greg at gregweber.info> wrote:
>>>
>>>>
>>>> On Tue, Apr 14, 2015 at 11:38 AM, Michael Sloan <mgsloan at gmail.com>
>>>> wrote:
>>>>
>>>>>     data SomeException = forall e . Exception e =>
>>>>>         SomeExceptionWithInfo e [SomeExceptionInfo]
>>>>>
>>>>>     data SomeExceptionInfo = forall a . ExceptionInfo a =>
>>>>>         SomeExceptionInfo a
>>>>
>>>>
>>>> Is it necessary for SomeExceptionWithInfo to have a list of a forall
>>>> data type?
>>>> Are Exceptions really that mysterious, or can we more concretely
>>>> describe the information that should be attached to an exception?
>>>>
>>>>     SomeExceptionWithInfo e IsAsync CallStack ImplicitStack
>>>>
>>>
>>> I did consider this option, but I think as soon as a fixed set is
>>> selected, someone's going to put something else in it.  Usually we wouldn't
>>> want to use such a 'dynamic' mechanism in Haskell, but it's appropriate for
>>> something so global as the type used to throw exceptions.
>>>
>>
>> The usual approach is to use information hiding. We are being rescued by
>> pattern synonyms right now because the constructor is directly exported.
>> Why not hide what needs to be hidden to make this more extensible and use
>> smart constructors, etc?.
>>
>>
>>>
>>>
>>>> I am still open to the idea of adding a forall data scratchpad, but can
>>>> we at least try to specify some standard fields?
>>>>
>>>>     SomeExceptionWithInfo e IsAsync CallStack ImplicitStack
>>>> [SomeExceptionInfo]
>>>>
>>>
>>> This is an interesting idea.  I particularly see value in having
>>> 'IsAsync' be a part of the Exception.  This is because `throwIO` / `throw`
>>> would need to set this to False when rethrowing async exceptions.
>>>
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150426/e73d38f1/attachment.html>