Re:Checked exceptions: Java’s biggest mistake (2014)
by elFarto on Friday September 11, 2020 @02:54PM
(#24446102)
There's also this magic function:
private static <T extends Throwable> T sneakyThrow(Throwable ex) throws T {
throw (T) ex;
}
Re:Checked exceptions: Java’s biggest mistake (2014)
by mumblemumble on Friday September 11, 2020 @01:19PM
(#24444997)
You can do that - I do it all the time myself - but I'd stop short of saying, "you'll be fine." That approach has its own downside, which is that it makes life obnoxious if you ever do want to actually handle exceptions. Then you'll have to add extra logic to determine if the exception you've caught is the actual error, or just a wrapper of some type. So your error handling inevitably becomes more error-prone.
If you can get your team to commit to a "let it crash" policy, though, then it's pretty doable.
Re:Checked exceptions: Java’s biggest mistake (2014)
by koolba on Friday September 11, 2020 @01:51PM
(#24445370)
You’ll end up double wrapping your exceptions though so your stack traces get a bit uglier.
Better to check if it’s a runtime exception and throw it again without wrapping it. Only wrap if it’s not a runtime exception. Also you should check if the thread was interrupted and, if so, set the interrupt flag again.
The worst part of this is having that dance littered throughout all your code.
Re:Checked exceptions: Java’s biggest mistake (2014)
by bobthepanda on Friday September 11, 2020 @01:54PM
(#24445409)
Lombok has @SneakyThrows which does pretty much this but without the additional wrapping.
try { //your code } catch (Exception e) { throw new RuntimeException(e); }
around it and you'll be fine.
The thing about Java is that the code lasts for a really long time because when it fails, it does so usually with an exception that points to the problem. When promises hang in NodeJS or memory corruption happens in C, it's much more annoying to track down problems.