Discussion: adding displayException to Exception class

[John Lato]

I guess I'm moderately sympathetic to the idea, although if I'm completely
honest it seems like a lot of make-work for little tangible benefit.

It would make more sense to me if there were also a push to make Read a
superclass of Exception, in which case Show should clearly be for
serialization (it is possible to make this work for
existentially-quantified data, but it would require manual instances).

It would make even more sense if Show were meant to be some sort of
user-readable string, and we used a different class (paired with Read) for
serialization.  Unfortunately that ship sailed long ago.

John L.

On Wed, Oct 29, 2014 at 7:43 AM, Michael Snoyman <michael at snoyman.com>
wrote:

> I don't want to make a format proposal yet, just open up discussion on an
> issue, and see how others feel about it.
>
> As I recently commented on this list[1], the Show typeclass is overloaded
> with multiple meanings (serialization, debug info, and user-friendly data
> display). The general consensus seems to be that the official semantics for
> Show should be for serialization (as paired up with Read).
>
> However, there's at least one use case in base which explicitly uses Show
> for non-serialization purposes: the Exception class. All instances of
> Exception are required to have an instance of Show, but there's no way to
> actually serialize exceptions generally[2]. So by construction and by
> practice, the Show instance for Exception is used exclusively for the
> latter two categories I mentioned (debug info and user-friendly data
> display).
>
> As a result of that, it's quite common[3] to define a Show instance for
> exception types that is *not* serializable, but rather user friendly. This
> however seems to contradict what is accepted as good practice in general.
>
>
> I have a possible solution that I'd like to propose as a strawman: add a
> new method to the Exception typeclass:
>
>     displayException :: e -> String
>     displayException = show
>
> The name is up for debate, but I chose `display` since it seems to already
> be used elsewhere for user-friendly output. Other possible choices are
> showException or prettyException. The default implementation will reuse the
> Show instance, so no user code will be broken by this[4].
>
> In the short term, the only other change I'd recommend is that the default
> exception handler use `displayException` instead of `show` for printing
> uncaught exceptions. Longer term, after deprecation cycles, we could
> consider removing the Show superclass from Exception.
>
> Again, this isn't a real proposal (yet), I'm more interested now in what
> people think about such a change.
>
> Michael
>
> [1] http://www.haskell.org/pipermail/libraries/2014-October/023957.html
> [2] Both due to how extensible exceptions work, and due to the lack of a
> Read superclass.
> [3] This discussion started when Chris Done and I were working with the
> tar package, which defines custom renderings for FormatError. I've
> implemented this same technique in some of my libraries, and I'm sure there
> are many other examples on Hackage.
> [4] Barring the standard issue of new identifiers clashing with
> identifiers defined locally.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141029/f5bfefed/attachment-0001.html>