Add exception type to messaged displayed by default exception handler

[tomjaguarpaw]

When an exception is printed by the default exception handler (through its show method, as it is now, or through its displayException, as it will be after #198), it can be hard to know what type the exception is (and therefore how one should catch it) or even that it is an exception at all. For example, it took me until about six months ago to even realize that the follow message was indicative of an uncaught exception, and it could be handled and recovered from. I thought it was an unrecoverable RTS error condition!

myprog: thread blocked indefinitely in an MVar operation

It would have been much more helpful to me if the message had been

myprog: thread blocked indefinitely in an MVar operation
Exception type: BlockedIndefinitelyOnMVar

Therefore I propose to add display of show (typeOf exn) to the default exception handler (defaultHandler in GHC/Conc/Sync.hs).

The proposed implementation is by @tbidne, at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11737 (which also adds package and module name information to the displayed message)

[parsonsmatt]

While we're at it, we may as well include the rest of the information that the TypeRep gives us - the defining package and module are extremely nice to have for figuring out how to handle/catch it.

[tbidne]

I like this idea.

@tomjaguarpaw Yes, done at #231, though if this passes I would prefer not to be involved in implementation since I am rather short of spare cycles right now.

I can help with implementation if that is agreeable.

[tomjaguarpaw]

I can help with implementation if that is agreeable.

Thanks!

[tbidne]

I created a draft PR to furnish discussion: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11737. Here's an example of what this could look like:

Main: thread blocked indefinitely in an MVar operation
HasCallStack backtrace:
CallStack (from HasCallStack):
  collectBacktraces, called at libraries/base/GHC/Exception.hs:67:13 in base:GHC.Exception
  toExceptionWithBacktrace, called at libraries/base/GHC/IO.hs:278:11 in base:GHC.IO
  throwIO, called at Main.hs:15:16 in main:Main

Package: base
Module: GHC.IO.Exception
Name: BlockedIndefinitelyOnMVar

Note that the implementation is not quite as straightforward as merely calling typeOf, as that is defeated by the dynamic casting. See the issue for details.

[parsonsmatt]

Ah, this is something I run into frequently. There are a bunch of wrapper types. Ultimately, to catch an exception at a given type, the fromException implementation has to work out. So ideally you're printing out the type at which you can call try or catch and catch the underlying exception. So doing typeOfException (SomeException e) = typeOf e is probably the right choice. Getting any more involved feels like a bigger and more invasive change, which distracts from the real benefit: knowing wtf was thrown

Otherwise, how do you want to represent the wrappers?

[tbidne]

Okay, I am convinced to go with the simpler implementation, calling typeOf on SomeException's param, but going no further. Your fromException insight (thanks!) illustrates a way to obtain more precise type information, at the cost of manual intervention.

Say your program dies with some unknown wrapper exception:

main :: IO ()
main = throwWrapper

λ. ./Main
Main: MkEx1 "some error"
HasCallStack backtrace:
CallStack (from HasCallStack):
  collectBacktraces, called at libraries/base/GHC/Exception.hs:67:13 in base:GHC.Exception
  toExceptionWithBacktrace, called at libraries/base/GHC/IO.hs:278:11 in base:GHC.IO
  throwIO, called at Main.hs:88:3 in main:Main
  throwWrapper, called at Main.hs:32:8 in main:Main

Package: main
Module: Main
Name: Wrapper

Upon seeing Wrapper, we can modify main to catch this and inspect its arguments, obtaining more precise info:

main :: IO ()
main = throwWrapper `catch` (\(MkWrapper e) -> throwIO e)

λ. ./Main
Main: Ex 1: some error
While handling: MkEx1 "some error"
HasCallStack backtrace:
CallStack (from HasCallStack):
  collectBacktraces, called at libraries/base/GHC/Exception.hs:67:13 in base:GHC.Exception
  toExceptionWithBacktrace, called at libraries/base/GHC/IO.hs:278:11 in base:GHC.IO
  throwIO, called at Main.hs:88:3 in main:Main
  throwWrapper, called at Main.hs:32:8 in main:Main


HasCallStack backtrace:
CallStack (from HasCallStack):
  collectBacktraces, called at libraries/base/GHC/Exception.hs:67:13 in base:GHC.Exception
  toExceptionWithBacktrace, called at libraries/base/GHC/IO.hs:278:11 in base:GHC.IO
  throwIO, called at Main.hs:32:48 in main:Main

Package: main
Module: Main
Name: Ex1

Also, it's nice to see the new callstack functionality working out.

[Bodigrim]

@tomjaguarpaw @tbidne did you converge to a final proposal? Could you possibly update the top post?

[tomjaguarpaw]

I'm happy with @tbidne's current draft implementation. @tbidne: are you content if I add it to the top post as the officially proposed version?

[tbidne]

@tomjaguarpaw @Bodigrim I am happy with the current implementation.

[tomjaguarpaw]

I have updated the top post. Could I call a vote please @Bodigrim?

[Bodigrim]

Dear CLC members, let's vote on the proposal to enhance the default top-level exception handler to display not only an exception message (which does not suggest which exception type was uncaught), but also the type and the provenance of the exception. The MR is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11737/diffs.

Before:

myprog: thread blocked indefinitely in an MVar operation

It's indeed hard to figure out not only which exception it is, but also that it is an exception at all (and not an irrecoverable RTS failure like a segfault).

After:

myprog: thread blocked indefinitely in an MVar operation
Package: base
Module: GHC.IO.Exception
Name: BlockedIndefinitelyOnMVar

(The message gets even better with exception backtraces, which we discuss in #201 and #202).

@tomjaguarpaw @mixphix @parsonsmatt @angerman @velveteer @hasufell

---

+1 from me, a clear improvement.

[angerman]

+1

[tomjaguarpaw]

+1

[velveteer]

+1