3 ms·

> unlike exceptions, they force callers to handle all potential outcomes, but no more. Checked exceptions in java also have that property. > they support map,

by shawnz 3y ago

> unlike exceptions, they force callers to handle all potential outcomes, but no more. Checked exceptions in java also have that property. > they support map, flatmap, applicative etc, making it easy to eg chain multiple computations together in desired ways, which is unwieldy and bug prone when using exceptions. Isn't that exactly the kind of thing this proposal aims to improve upon? > What is wrong about dedicated syntax [...] It adds complexity to the language! It sounds like you're basically arguing that the less syntax a language supports, the easier it is to use. But poll some beginner programmers about which language they find easier to use between Lisp and Python and I'm certain they'll say Python. Syntax has a purpose and if you take all the complexity out of the syntax then you'll just be pushing that complexity into the standard library instead. That's not inherently better, and personally I think it makes more sense to distribute that complexity across the various tools involved. That way, the syntax of the language can align better with the way we read and interpret natural language, and make it easier to process some of that complexity.

bedobi 3y ago
> Checked exceptions in java also have that property No they don't. How many times have you seen code like try { //whatever } catch (Exception e) { //now we're catching ALL exceptions, yay } or, worse try { //whatever } catch (Error e) { //lol } re syntax, I guess some folks like more syntax but the point is if the syntax is being added to solve a problem that's solved in a way that's strictly objectively better in another way, it's pointless (and we're not talking about just complex syntax and all the foot guns and complexity that comes with hierarchies with exceptions, differences between checked and unchecked etc etc, we're talking about actual execution - try catch is at the end of the day a JVM hack that slows down execution and does something weird which could be easily avoided by just returning plain objects
- shawnz 3y ago
  And in your scenario where you handle errors with an Either type, how many times have you seen code where that kind of thing just gets upcasted because the caller can't be bothered to deal with the specialized error? I think this is a strawman argument against exceptions and it's equally possible to do it wrong with your way as it is with my way.
  - vips7L 3y ago
    Rust: .unwrap() // error not possible Kotlin: someNullValue!!.doIt() //can't be null here

by shawnz 3y ago

bedobi 3y ago

> Checked exceptions in java also have that property No they don't. How many times have you seen code like try { //whatever } catch (Exception e) { //now we're catching ALL exceptions, yay } or, worse try { //whatever } catch (Error e) { //lol } re syntax, I guess some folks like more syntax but the point is if the syntax is being added to solve a problem that's solved in a way that's strictly objectively better in another way, it's pointless (and we're not talking about just complex syntax and all the foot guns and complexity that comes with hierarchies with exceptions, differences between checked and unchecked etc etc, we're talking about actual execution - try catch is at the end of the day a JVM hack that slows down execution and does something weird which could be easily avoided by just returning plain objects

shawnz 3y ago
And in your scenario where you handle errors with an Either type, how many times have you seen code where that kind of thing just gets upcasted because the caller can't be bothered to deal with the specialized error? I think this is a strawman argument against exceptions and it's equally possible to do it wrong with your way as it is with my way.
- vips7L 3y ago
  Rust: .unwrap() // error not possible Kotlin: someNullValue!!.doIt() //can't be null here