PROPOSAL: Add displayException to Exception typeclass

[Roman Cheplyaka]

On 10/11/14 09:56, Simon Hengel wrote:
>> 1.  Add a new method to the Exception typeclass:
>>
>>     -- | Render this exception value in a human-friendly manner. Default
>> implementation: @show at .
>>     displayException :: e -> String
>>     displayException = show
> 
> I'm +0.5 on this one, even though I think we should solve this in the
> general case.  I think there is a difference between converting
> something to a string (display) vs. showing something in a programmer
> friendly way (show).  This distinction is not novel, both Python and
> Ruby make that distinction (str()/repr() in Python, #to_s/#inspect in
> Ruby).
> 
> So I would love to have tho following type class:
> 
>     class Display a where
>       display :: a -> String
>       default display :: Show a => a -> String
>       display = show
> 
> Note that for many Prelude types `show == display`, with the notable
> exception of String, where `display = id`.  One use case where this
> matters is string interpolation [1][2][3].

I would also like a class like that to exist.

But I think it should be based on Text and Text builder rather than
String (and hence be outside of base).

Exceptions are an exception here (haha), because the class is in base,
and so cannot depend on Text. That's why a special method in that class
seems justified to me.

Therefore, I'm in favor of Michael's original proposal here.

>> 2. Modify GHC's default exception handler to use `displayException`
>> instead of `show`.
> 
> I'm -1 on this one.  From my perspective most of the time uncaught
> exceptions are encountered by programmers.  So I would prefer to have
> the programmer friendly version by default.  In cases where I want the
> "user friendly behavior" I'm ok with the extra step of adding a custom
> exception handler.  Ideally, we would already provide a convenient way
> to do so.

I guess this is fair.

Roman