[GHC] #12096: Attach stacktrace information to SomeException

[GHC]

#12096: Attach stacktrace information to SomeException
-------------------------------------+-------------------------------------
        Reporter:  ndtimofeev        |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              Version:  8.0.1
      Resolution:                    |             Keywords:  Exceptions
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by ekmett):

 Replying to [comment:17 ezyang]:
 > Your wiki page does comment that call stacks are preserved if you
 rethrow SomeException. But this often doesn't happen in practice. For
 example, the `system-fileio` example above rethrows an `IOError`: oops,
 call stack lost.

 Yes, there is no correct way to preserve this information that doesn't
 require the user signalling intent to us. Is what they are throwing a
 truly fresh exception or does it derive from one they were given?

 On the other hand, the very callstack was information you lacked to begin
 with in the old story.

 If we extend SomeException you can write code that is compatible with both
 the old and new story, and you can make a couple of one line tweaks to
 your code to make it so you can preserve the shiny new callstack
 information.

 If we extend _every_ exception type to carry this information then there
 is no code that has ever been written against the exception hierarchy that
 can survive the change. Moreover, the Exception class itself then has to
 provide a means for us to get in and find and replace the callStack in
 these user definable data types, and the user has to construct an empty
 callstack to throw their exception in the first place, all of which seems
 like a messy, invasive, and slow design.

 If we offer some subset of combinators (subject to bikeshedding) like

 {{{#!hs
 throwWithCallStack :: Exception e => e -> CallStack -> a
 withCallStack :: SomeException -> CallStack -> SomeException
 rethrow :: SomeException -> a
 rethrowAs :: Exception => SomeException -> e -> a
 throwIOWithCallStack, rethrowIO, rethrowIOAs ...
 catchWithCallStack :: Exception e => IO a -> (e -> CallStack -> IO a) ->
 IO a
 ...
 }}}

 to the user, then they can fix up these cases as they find them, and in
 the meantime they only get the callstack up to the last `throw`, which is
 __still__ more information than they have today.

 The same scenario involving destroying the source location happens in
 languages like c++ w/ throw vs rethrow.

 I personally am sad that extending `SomeException` with the callstack
 would mean my pretty little prisms into `SomeException` for the various
 exception types become a (convenient) lie, but I don't think the
 alternative of making the user decorate all of their exception types with
 a callstack, mangle every throw so that they include an empty callstack to
 kickstart the exception, and supply a callstack update function, and
 change all of their existing handlers, most of which do not rethrow, to
 deal with an extra argument is a terribly practical alternative.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12096#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler