4 ms·
Hm. I actually love how Java does exceptions. I think a little better conventions around when to use checked vs unchecked might help but generally I'd rather ch
by kjeetgill 8y ago
Hm. I actually love how Java does exceptions. I think a little better conventions around when to use checked vs unchecked might help but generally I'd rather checked exceptions be the norm than wholely absent.
What do you think is missing? My only ask would be syntax to capture an exception Future/Expression style for smaller use cases.
- cytzol 8y agoI think this is what you’re asking for with your last sentence, but I’m not sure so I’ll say it anyway: My main gripe with Java’s checked exceptions is that there’s no way to bubble up a checked exception from inside a functional interface, because the function signatures differ. For example, if you want to close a bunch of files, you can’t do `files.forEach(file -> file.close())` if the call to close throws IOException — you need to use an iterator (which is longer) or catch and re-throw it as a RuntimeException (which is much longer). Libraries like JOOL can help here, but not completely. It also doesn’t help that certain methods are declared as throwing exceptions that aren’t actually thrown, such as `ByteArrayOutputStream#close()`. I used to argue in favour of checked exceptions, but once I switched to Kotlin, I realised that I didn’t actually miss them at all. However, my other favourite language (Rust) uses something a lot closer to checked than unchecked, so maybe I’m just writing different kinds of code on the JVM to let me get away with having this opinion!