Discussion: adding displayException to Exception class

[Michael Snoyman]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141029/e39925fa/attachment.html>