3 ms·

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}!") }