Afaik, no language as great of exceptional handling as Java.
I prefer Go but I have to admit, Java's checked exception handling is amazing.
Frankly, Id rather have a result and optional/nullable type like in rust/kotlin than deal with exceptions in any capacity.
The correct way to deal with Java’s checked exceptions would have been introducing a Result type, or, preferably, type algebra, like in TypeScript, so something like:
fun openFile(fileName: String): File | FileNotFoundException {…}
Then you could handle it similarly to null: val content: String | FileNotFoundException = openFile(“myfile.txt”).?read()
…then you have to do a check before you use content as a String…
or val content: String = openFile(“myfile.txt”)?.read() ?: “File not found”
(There could also be other possible ways of handling the exception, like return on exception, jump to a handling block, and so on.)In fact, null should be treated as an exceptional value the same way all exceptions should be.
Having to deal with errors and forcing the developer to do proper error handling is a good thing.
Exceptions are not composable, cannot be generic, and it is not visible in the source code which lines can throw, so every line is a potential branching point.