Re: [Haskell-cafe] Decorating exceptions with backtrace information
On Fri, 8 May 2020, Niklas Hambüchen wrote:
On 5/8/20 5:37 PM, Henning Thielemann wrote:
a callstack is not useful for a user.
Call stacks have been very useful to me as a user of non-Haskell tools so far, because they are excellent for attaching to bug reports and usually led to developers fixing my problems faster.
This confirms that they are not for you, but you only forward them to the developer. Can someone please give me examples where current state lacks and how they are addressed by the proposal(s)?
Henning Thielemann
On Fri, 8 May 2020, Niklas Hambüchen wrote:
On 5/8/20 5:37 PM, Henning Thielemann wrote:
a callstack is not useful for a user.
Call stacks have been very useful to me as a user of non-Haskell tools so far, because they are excellent for attaching to bug reports and usually led to developers fixing my problems faster.
This confirms that they are not for you, but you only forward them to the developer.
Can someone please give me examples where current state lacks and how they are addressed by the proposal(s)?
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. Furthermore, even `base`'s own IO library (e.g. `openFile`) uses synchronous exceptions to report errors. This becomes particularly painful when building large systems: Even if I am careful to avoid such functions in my own code, as my dependency footprint grows it becomes more likely that some transitive dependency will expose a partial interface (perhaps even without my knowledge). This is a problem that industrial users are all too familiar with. Perhaps this helps to shed some light on the motivation? Cheers, - Ben
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'.
participants (2)
-
Ben Gamari -
Henning Thielemann