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

whatever, the point is exception allows and encourages people to catch less and more than they should

Sometimes top level code needs to do this. It's not always wrong. It's not always black and white in programming.

> 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

It has not been extremely/overwhelmingly rare in my experience. Further still, within the context of Java, exceptions are objects.

> 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.

This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one

...because doing the right thing should be convenient, for its own good.

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

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.

Was that comment meant for me?

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.

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

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

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.

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

> 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