
Rules
Risk Assessment Summary
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ERR00-J | Low | Probable | Medium | P4 | L3 |
ERR01-J | Medium | Probable | High | P4 | L3 |
ERR02-J | Medium | Likely | High | P6 | L2 |
ERR03-J | Low | Probable | High | P2 | L3 |
ERR04-J | Low | Probable | Medium | P4 | L3 |
ERR05-J | Low | Unlikely | Medium | P2 | L3 |
ERR06-J | Low | Unlikely | High | P1 | L3 |
ERR07-J | Low | Likely | Medium | P6 | L2 |
ERR08-J | Medium | Likely | Medium | P12 | L1 |
ERR09-J | Low | Unlikely | Medium | P2 | L3 |
6 Comments
Lothar Kimmeringer
There should be another rule: Don't catch Throwable without checking for ThreadDeath. Here is a non-compliant code-example:
This is often done if classes are loaded deferred using Class.forName where it's not sure if e.g. all necessary libraries are actually loaded. To prevent a NoSuchMethodError or NoClassDefFoundError being thrown up the whole system, the above construct is quite often be found. The problem is that this way ThreadDeath, an error being thrown if a Thread is stopped, will "get lost" preventing the Thread from being stopped.
Here is a compliant code-example:
If the logging should take place all the time, the following alternative can be used:
Dhruv Mohindra
I have a few reservations about the suggestion. According to the API,
ThreadDeath
-"An instance of ThreadDeath is thrown in the victim thread when the stop method with zero arguments in class Thread is called."
ThreadDeath
explicitly, I suppose this would not be required. Moreover, we are suggesting cooperative thread stopping (where a thread checks a boolean to terminate gracefully) so I am not sure how the logging can be hampered."An application should catch instances of this class only if it must clean up after being terminated asynchronously. If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies."
ThreadDeath
is being rethrown as required in your example so that looks good."The class ThreadDeath is specifically a subclass of Error rather than Exception, even though it is a "normal occurrence", because many applications catch all occurrences of Exception and then discard the exception."
ThreadDeath
can itself entangle multithreaded code. For one, this exception can be thrown anywhere making it difficult to trace and recover effectively. Also, there is nothing stopping a thread from throwing anotherThreadDeath
exception while recovery is in progress.Please feel free to outline your views on how this construct can be used safely; otherwise, it can possibly be classified as a separate rule warning against catching
ThreadDeath
. Thanks.Jonathan Paulson
It might be good to add [Rogue 2000] Rule 88: Use a {[finally}} block to release resources. The reasoning is that if you try to release resources in a block that could throw an exception, you might not release them, but a
finally
block will run regardless.Jérôme GUY
Hi
I think we should have a similar rule of the ERR00-C.
Don't you think ?
David Svoboda
Well, perhaps a recommendation is in order.
OTOH, C needs the recommendation much more than Java, because exceptions are universally used in Java.
Jérôme GUY
I mean that even if the exception mecanism is given by java it is necessary to well implement it (i have wrote nothing here
)
For example, if no design is done over all the application befor coding then developer may dont now what to do with its exceptions (may, he will only put a log systematicaly which is dramatic).
As for me, I would create a similar rule as ERR00-C