PROPOSAL: Add displayException to Exception typeclass

[Andreas Abel]

How about a compromise:

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

2.  Add a function that can be invoked to change the default handler.

Then one can easily install a generic handler that uses displayException.


On 10.11.2014 16:49, Roman Cheplyaka wrote:
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/