Discussion: adding displayException to Exception class

[Michael Snoyman]

On Wed, Oct 29, 2014 at 4:22 AM, Simon Hengel <sol at typeful.net> wrote:

> Hi Michael,
>
> > > Personally, I think it will be nice to be able to quickly identify the
> > > constructor of the exception.  Currently one has Google for the error
> > > message and hope for the best.
> >
> > Thank you for pointing that out. As it happens, that's the exact
> > conversation Chris and I had which led to this email ;).
>
> Same thought here, one of my main complaints about the current state of
> exceptions is that the default exception handler gives you no hint about
> the type of uncaught exceptions.
>
> For me uncaught exceptions are a programming error and I want output
> that helps me as a programmer to fix that programming error.  I don't
> care about "user-friendly data display" here.
>
> I think given the nature of hierarchical exceptions there is currently
> no generic way to show the exception type if the exception is at depth <
> 1 in the tree (for uncaught exceptions in Hspec I use the code at [1],
> which is better than using show but still not ideal).
>
> For this reason I *always* derive the Show instance if I define an
> exception type + I would prefer if Show instances for other exceptions
> would be derived, too (where possible).
>
> Would this proposal address this issue?  How exactly?  Could we just fix
> the (in my perspective) "broken" Show instances for standard exceptions
> instead?
>
>
>
>
We're coming from opposite ends on this one. I'm often writing user-facing
applications, where a failure message of `FailedConection "www.example.com"
80` is bad, and "Unable to make a connection to www.example.com on port 80"
is good. Both user-friendly and programmer-friendly display make sense,
they're just different use cases. And currently, they're shoe-horned into
the same `Show` instance.

As long as we're all in agreement that I'm not making a real proposal,
here's a solution to the problem: more methods! What about adding:

    displayException :: e -> String
    rawException :: e -> String -- meant to be the "serialized" version
like derived Show instances
    verboseException :: e -> String -- include module the type is defined
in, its package, data type, etc

We can give all of these default implementations as well. The downside is
that every possible usecase someone comes up with needs to go in Exception,
which doesn't scale past a certain point. The question then becomes: have
we already identified all of the use cases we care about?

A completely different approach that might be better for your use case
*and* might be useful in other cases would be to keep a stack of the
`TypeRep`s we converted through when creating the SomeException. However,
that would require a breaking change to SomeException, which I really
*don't* want to propose.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141029/e4d798e1/attachment.html>