Re:Java’s Checked Exceptions Are Evil? (2015)
by bluejekyll on Sunday September 23, 2018 @02:35PM
(#18052449)
Ultimately, the thing I most disagree with in the GP is the idea of handling and rewrapping. There a many cases where this would be bad practice.
Re:Java’s Checked Exceptions Are Evil? (2015)
by kjeetgill on Sunday September 23, 2018 @02:59PM
(#18052549)
It just depends I suppose? Sometimes you rewrap to get an unchecked runtime exception out of it. Sometimes there's context worth adding: new IndexLoadException(ioException, "Is Hadoop down?").
Either way I think the one thing I hate hate hate is, losing stacktraces! Don't throw a new exception without wrapping the old one. I need that info!
Re:Java’s Checked Exceptions Are Evil? (2015)
by EdwardDiego on Sunday September 23, 2018 @08:55PM
(#18054280)
> Either way I think the one thing I hate hate hate is, losing stacktraces! Don't throw a new exception without wrapping the old one. I need that info!
This! Throw as many RuntimeExceptions as you like, so long as you include the originating exception.
Re:Java’s Checked Exceptions Are Evil? (2015)
by bluejekyll on Monday September 24, 2018 @09:53AM
(#18057658)
Again I go back to InterruptedException, this advice is very wrong in that context, and similarly others.
People often make the very big mistake of generically catching Throwable and then rewrapping that, which would include all Error types. Those should must be rethrown without wrapping. I don’t think you meant to imply that, but it’s easy to overapply advice like this.
Which one is "default" depends on if you're writing library code, application code, or service code. Especially in services rethrow, catch all at the top, and log is common and makes sense.
Probably less appropriate for a zlib or a file not found call. You'll have to do something (unless the answer is crash ... Which it is a sometimes!)