Discussion: adding displayException to Exception class

[Roman Cheplyaka]

+1 to having separate methods for Show-like and human-friendly
displaying of exceptions.

Not sure if we need rawException — just using Show superclass in this
case seems appropriate.

On 29/10/14 04:33, Michael Snoyman wrote:
> 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