5 ms·

Agreed. I never understood the love for Either-based error handling in Haskell and other languages. It's such a bare bones system. If you add all the features t

Agreed. I never understood the love for Either-based error handling in Haskell and other languages. It's such a bare bones system. If you add all the features that people want from an error handling system, like stack traces; and remove the misfeatures that nobody wants, like Either<IOError,Either<MathError,Result>> being a pointlessly different type from Either<MathError,Either<IOError,Result>>; you end up with (surprise!) try-catch.

roblabla 7y ago
I'm not familiar with Haskell, but Rust's `Result` type is the same idea, and I wouldn't want to trade it for try-catch. It supports backtraces[0], has a simple way to turn errors into a "catch-all" type[1], but it is significantly less complex since it reuses the basic return value mechanism a function has. If you want to exit the program because the error can't be handled (similar to an unhandled exception), rust has a different concept for it, panics, and any Result can be turned into a panic via `unwrap()`. IMO both are important: panics represent unrecoverable errors, while Results can be acted upon (for instance, if read() returns Err(EINTR), you'll want to retry the read) [0]: Granted, you need to write some boilerplate to get the backtrace on error creation. [1]: You can cast all errors to `Box<dyn Error>`, a heap-allocated dynamically dispatched Error type.
- kmonsen 7y ago
  So in rust you write with result and in js you use try/catch. Pretty simple, and readers will understand the code.
  - roblabla 7y ago
    Oh I agree, and definitely don't recommend using Result in JS, the language is just not tailored for it. I was specifically addressing > I never understood the love for Either-based error handling in Haskell and other languages.
lmm 7y ago
> If you add all the features that people want from an error handling system, like stack traces; and remove the misfeatures that nobody wants, like Either<IOError,Either<MathError,Result>> being a pointlessly different type from Either<MathError,Either<IOError,Result>>; you end up with (surprise!) try-catch. What does a function that doesn't error look like under try-catch? How do you tell it apart from a function that can error. It's the same argument as null/Optional. Yes, Optional behaves the same as a nullable value; the point is that languages with Optional allow you to have values that aren't nullable.
- cousin_it 7y ago
  > What does a function that doesn't error look like under try-catch? How do you tell it apart from a function that can error. By the empty throws clause.
  - lmm 7y ago
    Edit: Parent was edited, previously suggested "Java-style exception specifications". As far as I know every language with "throws clause"s has the kind of problems I describe below though. Three major problems: they interact inconsistently with generics, you can no longer take a function's result and store it as a value, and you still can't tell whether a function might throw by looking at the point where it's called. A good version of exception specifications would be lightweight syntax sugar over either (in the same way that a good version of async/await is a lightweight syntax sugar over futures/promises). But I'm not aware of any language implementing that; I guess once you have working Either there's not enough value in providing an alternative syntax for it.
    - deleted 7y ago
      [deleted]
    - cousin_it 7y ago
      Actually I thought a bit and realized that I don't want to defend checked exceptions. Let me amend the previous answer to "I prefer such functions to be interchangeable".
chii 7y ago
why is either wrapped in eithers in your example? That feels like wrong code to me. Wouldn't it be Either<(MathError|IOError), Result>, and you pattern match the error or result?
0815test 7y ago
The types are definitely isomorphic, but the difference between them is not "pointless". You could have Either<IOError, Either<IOError, Result>> and want to preserve the information about which step led to an IOError outcome.
- deleted 7y ago
  [deleted]
- cousin_it 7y ago
  That information shouldn't be in the type, because it makes functions pointlessly non-interchangeable. With try-catch, a superset of that information is preserved in the stack trace, and functions stay interchangeable.
  - esarbe 7y ago
    I consider the error types to be a useful information that should absolutely be part of the method type. If a method can fail on IO that's different than if it cannot fail. And the surrounding code has to account for that. So, you might think that the methods are interchangeable if the error type is not present in the signature but this is actually wrong. Different failures have to be handled differently. (I assume that you are /not/ talking about valid error cases in the problem domain that also might have to be handled)
    - deleted 7y ago
      [deleted]

roblabla 7y ago

I'm not familiar with Haskell, but Rust's `Result` type is the same idea, and I wouldn't want to trade it for try-catch. It supports backtraces[0], has a simple way to turn errors into a "catch-all" type[1], but it is significantly less complex since it reuses the basic return value mechanism a function has. If you want to exit the program because the error can't be handled (similar to an unhandled exception), rust has a different concept for it, panics, and any Result can be turned into a panic via `unwrap()`. IMO both are important: panics represent unrecoverable errors, while Results can be acted upon (for instance, if read() returns Err(EINTR), you'll want to retry the read) [0]: Granted, you need to write some boilerplate to get the backtrace on error creation. [1]: You can cast all errors to `Box<dyn Error>`, a heap-allocated dynamically dispatched Error type.

kmonsen 7y ago
So in rust you write with result and in js you use try/catch. Pretty simple, and readers will understand the code.
- roblabla 7y ago
  Oh I agree, and definitely don't recommend using Result in JS, the language is just not tailored for it. I was specifically addressing > I never understood the love for Either-based error handling in Haskell and other languages.

lmm 7y ago

> If you add all the features that people want from an error handling system, like stack traces; and remove the misfeatures that nobody wants, like Either<IOError,Either<MathError,Result>> being a pointlessly different type from Either<MathError,Either<IOError,Result>>; you end up with (surprise!) try-catch. What does a function that doesn't error look like under try-catch? How do you tell it apart from a function that can error. It's the same argument as null/Optional. Yes, Optional behaves the same as a nullable value; the point is that languages with Optional allow you to have values that aren't nullable.

cousin_it 7y ago
> What does a function that doesn't error look like under try-catch? How do you tell it apart from a function that can error. By the empty throws clause.
- lmm 7y ago
  Edit: Parent was edited, previously suggested "Java-style exception specifications". As far as I know every language with "throws clause"s has the kind of problems I describe below though. Three major problems: they interact inconsistently with generics, you can no longer take a function's result and store it as a value, and you still can't tell whether a function might throw by looking at the point where it's called. A good version of exception specifications would be lightweight syntax sugar over either (in the same way that a good version of async/await is a lightweight syntax sugar over futures/promises). But I'm not aware of any language implementing that; I guess once you have working Either there's not enough value in providing an alternative syntax for it.
  - deleted 7y ago
    [deleted]
  - cousin_it 7y ago
    Actually I thought a bit and realized that I don't want to defend checked exceptions. Let me amend the previous answer to "I prefer such functions to be interchangeable".

chii 7y ago

why is either wrapped in eithers in your example? That feels like wrong code to me. Wouldn't it be Either<(MathError|IOError), Result>, and you pattern match the error or result?

0815test 7y ago

The types are definitely isomorphic, but the difference between them is not "pointless". You could have Either<IOError, Either<IOError, Result>> and want to preserve the information about which step led to an IOError outcome.

deleted 7y ago
[deleted]
cousin_it 7y ago
That information shouldn't be in the type, because it makes functions pointlessly non-interchangeable. With try-catch, a superset of that information is preserved in the stack trace, and functions stay interchangeable.
- esarbe 7y ago
  I consider the error types to be a useful information that should absolutely be part of the method type. If a method can fail on IO that's different than if it cannot fail. And the surrounding code has to account for that. So, you might think that the methods are interchangeable if the error type is not present in the signature but this is actually wrong. Different failures have to be handled differently. (I assume that you are /not/ talking about valid error cases in the problem domain that also might have to be handled)
  - deleted 7y ago
    [deleted]