I personally much prefer Rust style Result which also can't be ignored, and puts fallibili5y in the function signature.
In Java exceptions can be part of a method's declared type information, so handling is checked at compile time and IDEs can display the info.
Unfortunately certain Java missteps made this design unpopular these days. For example, for many years new String(bytes, "UTF-8"); made it mandatory to catch a UnsupportedEncodingException despite the language spec guaranteeing UTF-8 would be available. A later version of Java addressed it, but still...
For Rust result in C++ you have optional and expected. But they have their own problems, like rewriting function signatures all the way up the stack if you notice an error was possible when adding code.
But it enables incremental addition of errors and you can decide later what to do exactly, so I still tend to see it as an advantage.
It is like defer the error handling and centralize later.
If you want to handle an error in place immediately, prpbably it is not an exception what you want.
But if you need it is a fatal error, I do not see any harm, since the most you will do with that exception is to unwind and log or telemetry or whatever to tracke the errors.
Your code shouldn't need to make assumption about whether exception are being thrown or not.
Your mistake is thinking that a function potentially throwing means you need to catch it.