Java throwing exceptions

Question

In java there is the possibility of throwing an exception again, but does it have any advantage?

Answer 1

Sometimes you want some type of exception to be used in a method, but there are rare instances that throw other exceptions in the method. I often wrap the causal exception with my desired Exception, and then restore the desired exception.

This is really useful if you cannot determine that the exception caused your operation to fail until control is passed to the calling method (or one of its ancestors), because if the process ultimately fails, I can track back to stacktrace to understand why.

Answer 2

One example of when you want to reset an exception is that you really don't know how to handle it yourself, but you want to register that the exception was thrown. Reusing it allows you to grab the stack information that you need to register and pass the exception to the call stack for the calling user.

Answer 3

Sure. If you need to perform some special processing (logging, cleaning, etc.) for an exception, but cannot completely “handle” it, processing is usually performed, and then the exception is thrown. Note that in many cases (especially to clear resources) you probably need a finally clause rather than a catch / rethrow.

Answer 4

I have not done Java for many years, but from what I remember, just like other languages ​​with exceptions and OO. Exceptions can be subclassed, and often you want to catch the base class of many exceptions, but you cannot handle all of them. Say you handle remote file transfers and want to catch all IOErrors because you handle most of them, but not DiskFull. You can change this, and let someone else handle this down the chain, but deal with other issues, such as TransmissionFailed, by re-transmitting the transmission.

Answer 5

If you can somehow justify that you need to throw the same exception that you caught, I would say that something is wrong with your design.

Capturing one exception and rethrowing another makes sense. For example, you might want to add detailed information that there was no original exception.

Answer 6

Real world cases

Here are some real-world situations in which I needed to reverse engineer Java exceptions:

• When calling JDBC, I will catch a SQLException. However, postgres will throw a PSQLException with additional data and status. When testing extreme cases, we were able to corrupt the database, and we wanted the registrar to have very specific data about the exception and state. We are collecting the original exception in the new exception with a lot of data about server status and retron.
• When implementing a text analyzer, I would like to catch a number of runtime parsing exceptions, such as a NumberFormatException, and pass them to the stack with additional data about what text was called and the text source that caused the parsing exception.
• My colleague told me about the project in which he worked, where each exception was wrapped in another exception from one of two types - RetryableException and FatalException. In the case of a Retryable exception, the application will wait and retry the operation after a certain period of time. I'm not quite sure how I feel about this design, but I see it as a period of time to solve some transactional problems.
• In some cases, I would use an existing API that had throws defined for a high-level exception, and I would perform an operation that would throw an unbound exception (which I actually considered a RuntimeException) - I would then restore the exception as the cause of the more general exception.
• The purest case that I can think of in which you might want to repeat the exception is when you want to add additional data to it. For instance:

  public bizMethod() throws CoolBizLogicException { int policyId = getPolicyId("bar"); try { coolBizLogic(foobar); // this throws an exception } catch (CoolBizLogicException cble) { cble.setPolicyId(policyId); throw cble; } } 

Answer 7

I do not think so. If you can't handle it, don't get it.