HAhaskellhater·Dec 6, 2017
>> Not only do you constantly have to wrap and unwrap potential error values to
>> unify different error types
>
> This is a legitimate issue, although in Haskell you can use one error type
> like Go does if you want to.
SomeException is pretty much equivalent to Go's error, but it's not commonly
returned by libraries and such so using it barely helps with the need to
convert often. In addition all the types used by libraries as error values now
need to have Exception implemented, which they don't. So, in practice, no, you
cannot. Or rather, it wouldn't solve the core problem and create a new one.
>> And as if that wasn't bad enough, there are also actual throw/catch-style
>> exceptions, which are not checked in anyway
>
> This is also the case in Go (panics and recover).
True, panic/recover exist, but in practice I find them to be more a
Read the rest
kin to
setjmp/longjmp in C than throw/catch-style exceptions in other languages. Off
the top of my head I can't recall a case where I had to recover from a panic
that I didn't create in my own code (i.e. originated in a library call).
Exceptions in Haskell and other languages on the other hand are usually all
over the place (ok, usually not in pure code in Haskell) and I feel like I have
to constantly keep them in mind to avoid letting one slip through the seams and
then later having to track down where the hell that one came from.
>> I stopped writing Haskell maybe a year ago, but at least back then getting
>> GHC to print a stack trace when an exception wasn't caught was a major feat
>> that involved recompiling every single one of your hundreds of dependencies
>> with profiling flags.
>
> This is also the case in Go. Errors do not retain anything about their state.
> You need to use a package like https://github.com/go-errors/errors, which has
> the exact same issue you describe with dependencies.
That's fair and indeed it would often be handy to know where an error came
from. But since errors are just return values I don't really expect them to
have a stack trace attached to them, just like I don't expect any other value
to have that. It would still be neat for debugging sometimes, more so for
errors than other values. I think there are some proposals for improving on
this in Go 2.
What really frustrated me about Haskell though was debugging throw/catch-style
exceptions without a stack trace, because I basically had zero clues about
where it came from and there were no clear paths to trace in the code. In Go on
the other hand, errors don't just plop up from out of nowhere and panics, which
can, print a nice stack trace when not recovered from.