Opened 3 years ago

Last modified 9 months ago

#8875 new feature request

Track Exceptions

Reported by: yokto Owned by:
Priority: normal Milestone:
Component: Compiler Version:
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Figure out for each function which exceptions can be thrown by it. This could probably be done by tracking calls to




and their types. The info would probably need to be stored in the .hi files, and could then be displayed by haddock.

Change History (3)

comment:1 Changed 3 years ago by schyler

I sense confusion about the point of .hi files. Without going into too much detail why this ticket doesn't make sense for the current implementation of exceptions, this is a haddock feature request and not one for ghc (thus, it doesn't belong here).

Last edited 3 years ago by schyler (previous) (diff)

comment:2 Changed 3 years ago by yokto

Ok i'm not sure about the .hi file and i don't know a lot of haddock/ghc internals. But this seems pretty impossible to implement without a little help from the compiler.

comment:3 Changed 9 months ago by bgamari

While you might be able to track this for synchronous exceptions, tracking asynchronous exceptions would be nearly impossible given that anyone might throw you anything at any time.

Even if you are okay with this limitation, identifying which exceptions a function might throw is a non-trivial task which would require some sort of inter-procedure analysis, especially when you account for the fact that an exception handler may dynamically choose not to handle a given exception.

To make matters worse, the only exception handling constructs that the compiler currently knows about are throw# and catch# (and some variants), which know nothing of exception types (they merely expect some boxed Haskell value, which is typically a SomeException which packages an exception value together with a Typeable dictionary so we can reconstruct the type later).

So, while it might be possible to implement some approximation of what is requested here, it doesn't seem to me like the complexity of such an implementation would pull its weight. Moreover, you can get much of what you have requested in the type system, either by encoding errors in the result type of your computation or some other encoding of checked exceptions (e.g.

Last edited 9 months ago by bgamari (previous) (diff)
Note: See TracTickets for help on using tickets.