Re: [Haskell-cafe] Decorating exceptions with backtrace information
On 5/12/20 10:55 PM, Henning Thielemann wrote: > "This operation may fail with: > > * ResourceVanished if the handle is a pipe or socket, and the reading end is > closed." > > That is, ResourceVanished is part of the public interface and in no way > unexpected (or what "unintended" may be). I would prefer to make this > explicit in the type of hPutBuf: > > hPutBuf :: > (ResourceVanishedException e) => > Handle -> Ptr a -> Int -> ExceptT e IO () > > Now, what do you intend to do with the call-stack? Isn't it something you can > attach to the e value? Why is this relevant? The point of debugging is to find programming errors. It does not matter what the Haddocks say; if a programmer uses the function wrong, the exception will occur. hPutBuf does not currently have that type, nor can anybody rewrite all the existing libraries easily. The point of the proposal is to make the RTS help us debug problems in code as it exists today. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Decorating exceptions with backtrace information
On Fri, 8 May 2020, Ben Gamari wrote: Henning Thielemann writes: We are talking about the HasCallStack stack traces, yes? How is their emission addressed by extending exceptions with stack traces? HasCallStack stack traces are one type of backtrace that the proposal supports. However, it's not the only (nor is it even the most useful sort, in my opinion). Other mechanisms include cost center stacks from the cost-center profiler and native stack unwinding. Interesting. That's a completely new thing. * Developers cannot easily produce stack traces do debug unintended exceptions. What are "unintended exceptions"? What is an example of an "unintended exception"? For instance, * Somewhere deep in my code a colleague used `fromJust` due to a miscommunicated invariant That's a programming error. * Somewhere in my system a `writeFile "tmp" $ repeat 'a'` failed due to filling the disk Hm, that's also a programming error, but it ends in an IO exception. If it would not end in an IO exception (e.g. writing to /dev/null) it would go to an infinite loop. Anyway, it is a programming error. However it is an unchecked one. That is, there is no warranty that you can catch it by a debugger. So I do not think you can achieve much with callstacks here. * Somewhere in my system I have a partial pattern match in a module which was compiled without -Wall Programming error and btw. before thinking about a GHC extension I would enable -Wall ... * Somewhere in my system I `div` by zero due to lack of input validation Programming error * I use a record selector on a sum. Programming error * A logic error results in an assertion failure deep in my program, but it's unclear which path my program took to arrive at the assertion Sounds like Programming error This list could go on and on... From your list of examples I deduce that the proposal is about programming errors. But we have HasCallStack for that one. How does the proposal improve or alter the HasCallStack solution? And how does it relate to the IO exception system with hierarchical exceptions and SomeException and so on? Currently the proposal does not cover asynchronous exceptions but it wouldn't be particularly hard to extend it in this direction. This would allow far better reporting of heap/stack overflows and MVar deadlocks (which are particularly hard to debug at the moment). Hm, what kind of heap or stack overflow are you thinking of? A stack overflow sounds like unlimited recursion and thus like a programming error. In contrast to that, a program must be prepared for a failure of "malloc". Memory exhaustion is an IO exception, it should be explicit in the type. Are MVar deadlocks always detected by the runtime system? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Decorating exceptions with backtrace information
On Fri, 8 May 2020, Ben Gamari wrote: We can debate whether partial functions like `fromJust` should exist; however, the fact of the matter is that they do exist and they are used. That's not my point. I say: fromJust on Nothing is a programming error, ok. We must debug this. HasCallStack helps here. However, it does not have to do with exceptions or with the proposals as I understand them. Furthermore, even `base`'s own IO library (e.g. `openFile`) uses synchronous exceptions to report errors. Right. I say: Such exceptions are part of the public interface and should be expressed in types. If you encounter any problems when not doing this, I would first try to solve the problem with exceptions explicit in the type. E.g. Haddock for openFile says: This operation may fail with: * isAlreadyInUseError ... * isDoesNotExistError ... * isPermissionError ... Thus the type should be: openFile :: (AlreadyInUseException e, DoesNotExistException e, PermissionException e) => FilePath -> IOMode -> ExceptT e IO Handle Perhaps this helps to shed some light on the motivation? Unfortunately no. I only see the immortal confusion about (programming) errors vs. (IO) exceptions. And I think that part of this confusion is that IO exceptions in 'base' are hidden in the IO type and that there are hybrid functions like 'throw' that can be called like 'error' but they cause IO exceptions that can be caught by 'catch'. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Decorating exceptions with backtrace information
On Fri, 8 May 2020, Niklas Hambüchen wrote: What are "unintended exceptions"? What is an example of an "unintended exception"? A recent example from my production server: hPutBuf: resource vanished (Broken pipe) Ok, I lookup the Haddock comment of hPutBuf and it says: "This operation may fail with: * ResourceVanished if the handle is a pipe or socket, and the reading end is closed." That is, ResourceVanished is part of the public interface and in no way unexpected (or what "unintended" may be). I would prefer to make this explicit in the type of hPutBuf: hPutBuf :: (ResourceVanishedException e) => Handle -> Ptr a -> Int -> ExceptT e IO () Now, what do you intend to do with the call-stack? Isn't it something you can attach to the e value?___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Inclusion of the parser refactor in 8.12
This would also help to resolve https://github.com/digital-asset/ghcide/pull/350#discussion_r370878197, where we cannot get ApiAnnotations and Haddock comments at the same time. On Tue, 12 May 2020 at 18:38, Karpov, Mark wrote: > Hello, > > I'd like to mention that it would be nice if this patch > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377 could be > included in 8.12. Right now we have a few issues that Ormolu users have > reported which stem from how Haddocks are parsed by GHC (e.g. that issue > when a file starts with haddock it must have a module header). I originally > planned to work on those myself, but today I discovered that Vlad is > already working on it. > > Best, > > Mark > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Inclusion of the parser refactor in 8.12
Hello, I'd like to mention that it would be nice if this patch https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377 could be included in 8.12. Right now we have a few issues that Ormolu users have reported which stem from how Haddocks are parsed by GHC (e.g. that issue when a file starts with haddock it must have a module header). I originally planned to work on those myself, but today I discovered that Vlad is already working on it. Best, Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
