#8875: Track Exceptions ----------------------------+---------------------------------------------- Reporter: yokto | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8875#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8875: Track Exceptions -------------------------------------+------------------------------------- Reporter: yokto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: 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 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 wait. 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. http://www.well-typed.com/blog/2015/07/checked-exceptions/). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8875#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler