Proposal: Add exception info

Sun Apr 26 23:18:18 UTC 2015

On Sun, Apr 26, 2015 at 2:37 PM, Edward Kmett <ekmett at gmail.com> wrote:

> 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! =/
>

Yep, I agree that giving up this property sucks.  It's discussed at the end
of the proposal.

Rummaging through the list of decorations also sucks.  My reasoning for
that being acceptable is that if these annotations are used primarily for
diagnostic purposes, then performance isn't so crucial.

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.
>

To me, whether we use closed or open datatypes is tertiary to the main
issue of how info gets associated with exceptions.  If the main issue with
my proposal is the breakage of the information preservation of
`fromException`, as far as I can tell, that is not addressed by Davean's
proposal.  So, the narrowing of scope bought us nothing but having simpler
types to talk about.

One thing to note is that `fromException` does not guarantee preservation
of information.  So, this only breaks an informal property, not one that is
documented.  Admittedly, it's one that people are used to relying on.

> 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.
>

Yes, such core changes should be made with great care.  I hesitated to post
the proposal due to this, but was hoping that a more palatable, backwards
compatible solution would come up in discussion.

While I don't want to get stuck with a bad API, I also don't want to be
stuck with uninformative exceptions.  The new parts of the API can be stuck
in an "Internal" module, and marked specifically for debugging purposes
only.  This way, base reserves the right to revert this particular API
choice if a better option comes along.

Personally, I want callstacks for every exception thrown, and that's what
this proposal provides.

> -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/f16130b3/attachment.html>