There seem to be multiple beginnings of the discussion. What is currently
discussed?
If someone says "exceptions" and "backtrace" in one sentence, I suspect
like many times before, that again confusion of the concepts of exceptions
and errors is ahead. Errors already support call stacks. Why should
exceptions get them, too? Exceptions should carry information that is
useful for a user, but a callstack is not useful for a user.
I can imagine that it would be helpful for the user to get a stacked
exception information like:
Parse error on line 42, column 23
while reading file "foo/bar"
while traversing directory "blabla"
But since you refer to the CallStack feature of GHC, this seems not to be
addressed in the proposals.
On Fri, 8 May 2020, Carter Schonwald wrote:
I have no doubt such a mechanism would have saved me many hours of
debugging exceptions in Haskell systems I've worked on in the past.
If you must debug exceptions, then this sounds like exceptions were abused
for programming errors.
Ben writes in:
http://www.well-typed.com/blog/2020/04/dwarf-3/
"Unfortunately, the untyped nature of Haskell exceptions complicates the
migration path for existing code."
Actually, it only proves again, that it was wrong from the beginning to
hide information about potential exceptions in the IO monad instead of
making them explicit via ExceptionalT, ExceptT or the like.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
