Hacker News new | ask | show | jobs
by mercurial 4257 days ago
> Having written probably in the high thousands or low tens of thousands of LoC of Haskell, I've never once used a user-defined exception or undefined.

Good for you, I guess. You'll find plenty of libraries which have no qualms about using exceptions in the real world, though. Not to mention asynchronous exceptions, obviously. Personally, I find both exceptions and type-safe error handling unsatisfactory. The former is unsafe, the latter results usually in a "god error type" which breaks modularity.
1 comments
wyager 4257 days ago
>plenty of libraries which have no qualms about using exceptions in the real world

I haven't run into too many (particularly when compared to the popularity of exceptions in other languages).

>the latter results usually in a "god error type" which breaks modularity.

Have you tried using Either with a sum error type and/or an error typeclass?

link
mercurial 4257 days ago
> I haven't run into too many (particularly when compared to the popularity of exceptions in other languages).

This doesn't mean much if you take a language like Java where it is the idiomatic way of handling errors. But take something vaguely complex like http-client (formerly http-conduit) and you get exceptions.

> Have you tried using Either with a sum error type and/or an error typeclass?

Well, even with sum types you get "god errors" which encapsulate all kinds of issues that can happen in your exception, because it's the path of least resistance. I haven't tried Either with a typeclass, though, but it sounds vaguely abusive.

link
wyager 4257 days ago
>Well, even with sum types you get "god errors" which encapsulate all kinds of issues that can happen in your exception,

What's the alternative? Failing to encapsulate all kinds of issues that can happen?

link
mercurial 4256 days ago
Well, what I'd really want is something more flexible, where you can use inheritance (errors are one of the few areas where inheritance is actually useful - this lets you say that "FileNotFoundError" is a kind of "IOError", add "DimensionGateConnectionError" in the same hierarchy without tweaking any code, and test if the the IOError you got is because you didn't manage to open the dimensional gate. And on top of this, I'd also like this to compose without problems, I'm not interested in creating IOOrFormatError because there is a function which may throw IOError or FormatError. It's a problem that sum types really don't tackle well. As for type classes, it's also not ideal. You can't capture all the necessary information in the interface you expose (IOError doesn't need a filePath field, but FileNotFoundError, which is a kind of IOError does).
link