4 ms·

I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked e

I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked exceptions in java, there are still exceptions that aren't checked, and the syntax for the checking becomes monstrous.

vbezhenar 10y ago
Implicit return codes (e.g. return int, -1 means error, 0+ means OK) are equivalent to unchecked exceptions. Explicit return codes, where you must process them or compiler will yell at you are equivalent to checked exceptions. I think, that checked exceptions are a good idea, but they must be improved. E.g. Rust have syntax for almost implicit converting one error to another and return it; checked exceptions could use similar approach, so you can declare another exception in your "throws" cause and compiler'll generate conversion code for any unhandled checked exception. Anyway for me exceptions are way easier to work with, than return codes.
- jimktrains2 10y ago
  Yes, exceptions are better than return codes, but I would argue Result types are better than exceptions. Checked exceptions in Java have their issues. Exceptions in C++ are odd beasts (though that's getting better, they're still not checked and therefor basically anything that isn't noexcept can throw them (oh wait! noexcept can throw! it just crashes immediately)).
- quicknir 10y ago
  That equivalence is false. An unhandled exception bubbles up. An unhandled return code is ignored. This was exactly one of the biggest arguments against return codes.
jeremyjh 10y ago
The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it will ever be used in these contexts to begin with.
- jimktrains2 10y ago
  I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, not the break that exceptions provide. Third, it's useful for more than just "Exceptions". Coupled with Optional types, it provides a more expressive way of not-hapy-path-code where exceptions just feel heavy handed. For instance https://docs.python.org/3/library/stdtypes.html https://docs.python.org/3/library/stdtypes.html d[key] Return the item of d with key key. Raises a KeyError if key is not in the map. The key not existing isn't really exceptional. A proper optional, union, or result type handles this case much more easily. In sum, I think the expressibility of Result and Option, along with a more natural flow for handling them will make working around them less tempting/viable/easy to pass over in a code review.
  - jeremyjh 10y ago
    You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first place. I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.
    - jimktrains2 10y ago
      > I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions. Yeaaaaaaah. I remember being a very strong supporter of checked exceptions before I got into a giant codebase and saw how not having speced a sane exception type can cause lots of pain and some really long declarations or dropped exceptions. catch (Exception e) { throw new RuntimeError(e); } :( You're right, I guess time will tell.

vbezhenar 10y ago

Implicit return codes (e.g. return int, -1 means error, 0+ means OK) are equivalent to unchecked exceptions. Explicit return codes, where you must process them or compiler will yell at you are equivalent to checked exceptions. I think, that checked exceptions are a good idea, but they must be improved. E.g. Rust have syntax for almost implicit converting one error to another and return it; checked exceptions could use similar approach, so you can declare another exception in your "throws" cause and compiler'll generate conversion code for any unhandled checked exception. Anyway for me exceptions are way easier to work with, than return codes.

jimktrains2 10y ago
Yes, exceptions are better than return codes, but I would argue Result types are better than exceptions. Checked exceptions in Java have their issues. Exceptions in C++ are odd beasts (though that's getting better, they're still not checked and therefor basically anything that isn't noexcept can throw them (oh wait! noexcept can throw! it just crashes immediately)).
quicknir 10y ago
That equivalence is false. An unhandled exception bubbles up. An unhandled return code is ignored. This was exactly one of the biggest arguments against return codes.

jeremyjh 10y ago

The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it will ever be used in these contexts to begin with.

jimktrains2 10y ago
I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, not the break that exceptions provide. Third, it's useful for more than just "Exceptions". Coupled with Optional types, it provides a more expressive way of not-hapy-path-code where exceptions just feel heavy handed. For instance https://docs.python.org/3/library/stdtypes.html https://docs.python.org/3/library/stdtypes.html d[key] Return the item of d with key key. Raises a KeyError if key is not in the map. The key not existing isn't really exceptional. A proper optional, union, or result type handles this case much more easily. In sum, I think the expressibility of Result and Option, along with a more natural flow for handling them will make working around them less tempting/viable/easy to pass over in a code review.
- jeremyjh 10y ago
  You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first place. I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.
  - jimktrains2 10y ago
    > I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions. Yeaaaaaaah. I remember being a very strong supporter of checked exceptions before I got into a giant codebase and saw how not having speced a sane exception type can cause lots of pain and some really long declarations or dropped exceptions. catch (Exception e) { throw new RuntimeError(e); } :( You're right, I guess time will tell.