4 ms·
I think you both generally agree. The choice is either handle now, or rethrow and handle later. Which one is "default" depends on if you're writing library cod
by kjeetgill 8y ago
I think you both generally agree. The choice is either handle now, or rethrow and handle later.
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!)
- bluejekyll 8y agoUltimately, 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.
- kjeetgill 8y agoIt 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!
- EdwardDiego 8y ago> 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.
- bluejekyll 8y agoAgain 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.