3 ms·
In general it's hard to distinguish between a good idea executed badly and a bad idea executed badly. I think Java executed badly here. There doesn't seem to
by mjw1007 8y ago
In general it's hard to distinguish between a good idea executed badly and a bad idea executed badly.
I think Java executed badly here.
There doesn't seem to have been a clear policy in the standard library for what kind of exception should be checked, and there really ought to be a concise way to say "panic and abort the process" when that's appropriate.
Also, when you have checked exceptions (or similar things like error returns which it's compulsory to check), sometimes you need to add variants to library functions for cases which can't fail. For example, you might have a library function which takes a character-encoding parameter and can't fail if that encoding is UTF-8; you might be better off adding foo_utf8(x) which is like foo(x, UTF_8) except for the error specification.
- zokier 8y agoAgreed. I see checked exceptions as kinda parallel to Rusts Result type (and its older cousins), which people seem to like.
- kevinconaway 8y ago> there really ought to be a concise way to say "panic and abort the process" when that's appropriate. There is, it is the Error class and its subclasses, e.g. OutOfMemoryError
- mjw1007 8y agoI mean a bit more concise than that. To catch and rethrow an exception you still need a try and a block, and you probably add a level of indent. Compare Rust, where you can generally spell "I'm sufficiently confident that this won't happen that I'm happy to abort if it does" as « .unwrap() ». (That's not a great word for this idea, but it is at least short.)