4 ms·

This is exactly the opposite recommendation I give. Never handle an exception (always rethrow) unless you know that you can do something specific in that excep

This is exactly the opposite recommendation I give. Never handle an exception (always rethrow) unless you know that you can do something specific in that exceptional case. In most cases just rethrowing the exception is the correct thing, and many bugs come from people mishandling exceptions. A perfect example is InterruptedException, where really bad things happen if you don’t rethrow that. Just rethrow, it’s generally the best thing.

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 ago
  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.
  - kjeetgill 8y ago
    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!
    - 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 ago
        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.

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 ago
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.
- kjeetgill 8y ago
  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!
  - 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 ago
      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.