I read some code of a colleague and found that he often catches various exceptions and then always throws a 'RuntimeException' instead. I always thought this is very bad practice. Am I wrong?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I do not know enough context to know whether your colleague is doing something incorrectly or not, so I am going to argue about this in a general sense.
I do not think it is always an incorrect practice to turn checked exceptions into some flavor of runtime exception. Checked exceptions are often misused and abused by developers.
It is very easy to use checked exceptions when they are not meant to be used (unrecoverable conditions, or even control flow). Especially if a checked exception is used for conditions from which the caller cannot recover, I think it is justified to turn that exception to a runtime exception with a helpful message/state. Unfortunately in many cases when one is faced with an unrecoverable condition, they tend to have an empty catch block which is one of the worst things you can do. Debugging such an issue is one of the biggest pains a developer can encounter.
So if you think that you are dealing with a recoverable condition, it should be handled accordingly and the exception should not be turned into a runtime exception. If a checked exception is used for unrecoverable conditions, turning it into a runtime exception is justified.
It can be GOOD. Please read:
Throwing checked exceptions and not being able to recover from it is not helping.
Some people even think that checked exceptions should not be used at all. See http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html
Also from the same link:
No, you are not wrong. His practice is extremely misguided. You should throw an exception that captures the issue that caused it. RunTimeException is broad and over reaching. It should be a NullPointerException, ArgumentException, etc. Whatever accurately describes what went wrong. This provides the ability to differentiate issues that you should handle and let the program survive versus errors that should be a "Do not pass go" scenario. What he is doing is only slightly better than "On Error Resume Next" unless there is something missing in the info provided in the question.
This practice may be even wise. There are many situations (for example in web developement), where if some exception happens, you are unable to do anything (because you cannot for example repair inconsistent DB from your code :-), only developer can do it). In these situations, it is wise to wrap the thrown exception into a runtime exception a rethrow it. Than you can catch all these exceptions in some exception handling layer, log the error and display the user some nice localized error code + message.
On the other hand, if the exception is not runtime (is checked), the developer of the API indicates, that this exception is resolvable and should be repaired. If its possible, than you should definitely do it.
The other solution might be to rethrow this checked exception into the calling layer, but if you were unable to solve it, where the exception occured, you will be likely unable to solve it here also...
I would like to get comments on this, but I find there are times when this isn't necessarily bad practice. (Or terribly bad). But maybe i am wrong.
Often times an API you are using will throw an exception that you can't imagine actually being thrown in your specific usecase. In this case, it seems perfectly fine to throw a RuntimeException with the caught exception as the cause. If this exception is thrown, it'll likely be the cause of programming error and isn't inside the bounds for correct specification.
Assuming the RuntimeException isn't later caught and ignored, it's no where near an OnErrorResumeNext.
The OnErrorResumeNext would occur when someone catches an exception and simply ignores it or just prints it out. This is terribly bad practice in almost all cases.
We may rethrow a checked exception as a runtime exception if the propagating or interface code assumes that the underlying implementation depends on external state, when it clearly does not.
This section discusses the topic of when either of the exceptions should be thrown. You can skip to the next horizontal bar if you just want to read a more detailed explanation for the conclusion.
When is it appropriate to throw a runtime exception? You throw a runtime exception when it is clear that the code is incorrect, and that recovery is appropriate by modifying the code.
For instance, it is appropriate to throw a runtime exception for the following:
This will throw a division by zero runtime exception. This is appropriate because the code is defective.
Or for instance, here's a portion of
In order to fix the initial capacity or load factor, it is appropriate that you edit the code to ensure that the correct values are being passed in. It is not dependent on some far away server being up, on the current state of the disk, a file, or another program. That constructor being called with invalid arguments depends on the correctness of the calling code, be it a wrong calculation that led to the invalid parameters or inappropriate flow that missed an error.
When is it appropriate to throw a checked exception? You throw a checked exception when the issue is recoverable without changing the code. Or to put it in different terms, you throw a checked exception when the error is related to state while the code is correct.
Now the word "recover" may be tricky here. It could mean that you find another way to achieve the goal: For instance, if the server doesn't respond then you should try the next server. If that sort of recovery is possible for your case then that's great, but that's not the only thing recovery means -- recovery could simply be displaying an error dialog to the user that explains what happened, or if that's a server application then it could be sending an email to the administrator, or even merely logging the error appropriately and concisely.
Let's take the example that was mentioned in mrmuggles' answer:
This is not the correct way to handle the checked exception. The mere incapacity to handle the exception in this method's scope does not mean that the app should be crashed. Instead, it is appropriate to propagate it to a higher scope like so:
Which allows for the possibility of recovery by the caller:
Checked exceptions are a static-analysis tool, they make it clear for a programmer what could go wrong in a certain call without requiring them to learn the implementation or going through a trial and error process. This makes it easy to ensure that no portions of the error flow will be ignored. Rethrowing a checked exception as a runtime exception is working against this labor-saving static analysis feature.
It is also worth mentioning that the calling layer has a better context of the grander scheme of things as has been demonstrated above. There could be many causes for that
Now that we've got this distinction clear, we may proceed to deduce when it's ok to rethrow a checked exception as a runtime exception.
Given the above, when is it appropriate to rethrow a checked exception as a RuntimeException? When the code you are using assumes dependency on external state, but you can clearly assert that it does not depend on external state.
Consider the following:
In this example, the code is propagating
The reason for strictly keeping external state dependent exceptions checked is that they are not easily reproducible (unlike code or logic dependent exceptions, which will reproduce every time, immediately). Exceptions that depend on network connectivity being unstable, or integration with another external service that could vary in version or become disabled, such as a database for instance, may never be discovered in the office where connectivity is usually stable and the environment conditions are unlikely to be tempered with in great variance. These external state dependent exceptions have high chances of making it to production and they are easy to miss in test.
This is common practice in many frameworks. E.g.
For standalone applications. When you know your application cannot handle the exception you could, instead of throwing the checked RuntimeException, throw Error, let the application crash, hope for bug-reports, and fix your application. (See the answer of mrmuggles for a more in depth discussion of the pro's and con's of checked versus unchecked.)
This might depend on case to case basis. In certain scenarios it is wise to do what your friend is doing, for example when you are exposing an api for some clients and you want the client to be least aware of the implementation details, where you know that certain implementation exceptions may be specific to implementation details and not exposable to the client.
By keeping the checked exceptions out of the way, you can expose api's that would enable the client to write cleaner code as the client itself might be pre-validating the exceptional conditions.
For example Integer.parseInt(String) takes a string and returns the integer equivalent of it and throws NumberFormatException in case the string is not numeric. Now imagine a form submission with a field
There are really a couple of questions here
The general rule of thumb is that exceptions that the caller is expected to catch and recover from should be checked. Other exceptions (ones where the only reasonable outcome is to abort the whole operation or where you consider them unlikely enough that worrying about handling them specifically is not worth it) should be unchecked.
Sometimes your judgement on whether an exception deserves catching and recovery is different from that of the API you are working with. Sometimes context matters, an exception that is worth handling in one situation may not be worth handling in another. Sometimes your hand is forced by existing interfaces. So yes there are legitimate reasons to turn a checked exception into an unchecked exception (or to a different type of checked exception)
Firstly and most importantly make sure you use the exception chaining facility. That way the information from the original exception is not lost and can be used for debugging.
Secondly you have to decide what exception type to use. Using a plain runtimeexception makes it harder for the caller to determine what went wrong but if the caller is trying to determine what went wrong that may be an indication that you should not have changed the exception to make it unchecked.
The whole "checked exception" thing is a bad idea.
Structured programming only allows information to be passed between functions (or, in Java parlance, methods) when they are "nearby". More precisely, information can only move across functions in two ways:
This is a fundamentally good thing. This is what allows you to reason about your code locally: if you need to understand or modify a part of your program, you only need to look at that part and other "nearby" ones.
However, in some circumstances, it is necessary to send information to a "distant" function, without anyone in the middle "knowing". This is precisely when exceptions have to be used. An exception is a secret message sent from a raiser (whatever part of your code might contain a
Checked exceptions destroy the secrecy of the mechanism, and, with it, the very reason for its existence. If a function can afford to let its caller "know" a piece of information, just send that piece of information directly as a part of the return value.
In my opinion,
In the framework level, we should be catch runtime exceptions to reduce more block of try catch to the invoker in the same place.
In the application level, we rarely capture runtime exceptions and i think this practice was bad.
protected by gnat Feb 25 at 14:20
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?