5 ms·

> Checked exceptions however are as safe No. If I add a checked UserNotFound exception to a getUser db call, you can bet someone higher up the stack will do tr

by bedobi 3y ago

> Checked exceptions however are as safe No. If I add a checked UserNotFound exception to a getUser db call, you can bet someone higher up the stack will do try catch Exception e, so now they're catching OutOfMemory and who knows what else.

vips7L 3y ago
OutOfMemoryError isn't an exception so they would not be catching it.
- bedobi 3y ago
  whatever, the point is exception allows and encourages people to catch less and more than they should
  - vips7L 3y ago
    Sometimes top level code needs to do this. It's not always wrong. It's not always black and white in programming.
    - bedobi 3y ago
      > Sometimes top level code needs to do this come on, it's not as if anyone disagrees with that, but that's extremely, extremely rare, overwhelmingly, callers are just dealing things like with UserNotFoundException, NullPointerException, what have you, and there's no reason why the compiler should happily let you catch Exception (or nothing) when it could just be giving you an honest object back
      - wewtyflakes 3y ago
        It has not been extremely/overwhelmingly rare in my experience. Further still, within the context of Java, exceptions are objects.
twelve40 3y ago
> you can bet someone higher up the stack will do try catch Exception e But that's laziness on the caller's part. If I offer a method but the caller decides to do reckless lazy crap with it, there are many different ways to get there in any language. I typically call those out (Exception e) at code reviews.
- bedobi 3y ago
  This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one
  - esafak 3y ago
    ...because doing the right thing should be convenient, for its own good.
kaba0 3y ago
As opposed to force unwrapping a Result type? Also, OutOfMemory is an error, exceptions won’t catch it.
- DarkNova6 3y ago
  What about DivisionByZero, NumberFormatexception, ArrayStoreException? There are countless examples of rare but legit non-obscure use-cases. And even if your code is fine, you can't expect the same for the libraries you are using. And some exceptions make frequent non-happy paths more visible. Most of all IOException, because IO can _always_ fail for all the wrong reasons (because the failing of this exception is outside of the JVM's influence, it is rightfully a checked exception). And often you simply don't want to do the error handling at call-site but propagate to the code which is controlling the use-case.
  - kaba0 3y ago
    Was that comment meant for me?
- clhodapp 3y ago
  You can choose to unwrap the result type wherever you want, as opposed to it automatically unwrapping in place at the call site and having a weird propensity to encourage a "special" return from there.
- unscaled 3y ago
  Force-unwrapping a Result type is something you can do in multi-paradigm languages such as Rust, but not in stricter functional languages like Haskell - at least not easily (and we're worried about developers taking the easy way out here). But more importantly, force-unwrapping is not equivalent to catching generic exceptions. Instead, it's equivalent to catching all checked exceptions and wrapping them in a Runtime error. It's also almost equivalent to what this compiler plugin does (or Kotlin or Lombok's @SneakyThrows do). Catching "Exception" and trying to handle it generically, is more closely equivalent to this type of code: match result { Ok(value) => doSomethingWithValue(value) Err(e) => println("Error: {e}!") }
jbverschoor 3y ago
Then that person should get a Java 101 class. Or is this the current “staff software engineer” level of skills?
- bedobi 3y ago
  This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one. "Just get better" like oh ok except that in the real world people are gonna people and even the best programmers in the world make mistakes and do dumb, lazy shit. Our tools should be designed such that the safest, most correct way to do anything has the path of least the resistance. Not happily allow you to ignore exceptions, or catch less or more exceptions than required. Functional error handling corrects this, exceptions do not. Anyway, it's clear we're not going to agree, and you win, since so far the industry is still stubbornly clinging to exceptions, despite them being a failed feature in every language they're in.
  - jbverschoor 3y ago
    It’s not even lazy, your IDE will not do this for you by default. It’s got nothing to do with getting better. It IS basic Java exception handling. Any proper course or tutorial will tell you to catch specific exceptions
    - bedobi 3y ago
      > Any proper course or tutorial will tell you to catch specific exceptions any real world library or application will catch Exception e, catch checked exceptions and turn them into unchecked ones etc etc

by bedobi 3y ago

vips7L 3y ago

OutOfMemoryError isn't an exception so they would not be catching it.

bedobi 3y ago
whatever, the point is exception allows and encourages people to catch less and more than they should
- vips7L 3y ago
  Sometimes top level code needs to do this. It's not always wrong. It's not always black and white in programming.
  - bedobi 3y ago
    > Sometimes top level code needs to do this come on, it's not as if anyone disagrees with that, but that's extremely, extremely rare, overwhelmingly, callers are just dealing things like with UserNotFoundException, NullPointerException, what have you, and there's no reason why the compiler should happily let you catch Exception (or nothing) when it could just be giving you an honest object back
    - wewtyflakes 3y ago
      It has not been extremely/overwhelmingly rare in my experience. Further still, within the context of Java, exceptions are objects.

twelve40 3y ago

> you can bet someone higher up the stack will do try catch Exception e But that's laziness on the caller's part. If I offer a method but the caller decides to do reckless lazy crap with it, there are many different ways to get there in any language. I typically call those out (Exception e) at code reviews.

bedobi 3y ago
This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one
- esafak 3y ago
  ...because doing the right thing should be convenient, for its own good.

kaba0 3y ago

As opposed to force unwrapping a Result type? Also, OutOfMemory is an error, exceptions won’t catch it.

DarkNova6 3y ago
What about DivisionByZero, NumberFormatexception, ArrayStoreException? There are countless examples of rare but legit non-obscure use-cases. And even if your code is fine, you can't expect the same for the libraries you are using. And some exceptions make frequent non-happy paths more visible. Most of all IOException, because IO can _always_ fail for all the wrong reasons (because the failing of this exception is outside of the JVM's influence, it is rightfully a checked exception). And often you simply don't want to do the error handling at call-site but propagate to the code which is controlling the use-case.
- kaba0 3y ago
  Was that comment meant for me?
clhodapp 3y ago
You can choose to unwrap the result type wherever you want, as opposed to it automatically unwrapping in place at the call site and having a weird propensity to encourage a "special" return from there.
unscaled 3y ago
Force-unwrapping a Result type is something you can do in multi-paradigm languages such as Rust, but not in stricter functional languages like Haskell - at least not easily (and we're worried about developers taking the easy way out here). But more importantly, force-unwrapping is not equivalent to catching generic exceptions. Instead, it's equivalent to catching all checked exceptions and wrapping them in a Runtime error. It's also almost equivalent to what this compiler plugin does (or Kotlin or Lombok's @SneakyThrows do). Catching "Exception" and trying to handle it generically, is more closely equivalent to this type of code: match result { Ok(value) => doSomethingWithValue(value) Err(e) => println("Error: {e}!") }

jbverschoor 3y ago

Then that person should get a Java 101 class. Or is this the current “staff software engineer” level of skills?

bedobi 3y ago
This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one. "Just get better" like oh ok except that in the real world people are gonna people and even the best programmers in the world make mistakes and do dumb, lazy shit. Our tools should be designed such that the safest, most correct way to do anything has the path of least the resistance. Not happily allow you to ignore exceptions, or catch less or more exceptions than required. Functional error handling corrects this, exceptions do not. Anyway, it's clear we're not going to agree, and you win, since so far the industry is still stubbornly clinging to exceptions, despite them being a failed feature in every language they're in.
- jbverschoor 3y ago
  It’s not even lazy, your IDE will not do this for you by default. It’s got nothing to do with getting better. It IS basic Java exception handling. Any proper course or tutorial will tell you to catch specific exceptions
  - bedobi 3y ago
    > Any proper course or tutorial will tell you to catch specific exceptions any real world library or application will catch Exception e, catch checked exceptions and turn them into unchecked ones etc etc