SEI CERT Oracle Coding Standard for Java
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata

Rules

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

ERR00-JLowProbableMedium

P4

L3

ERR01-JMediumProbableHigh

P4

L3

ERR02-JMediumLikelyHigh

P6

L2

ERR03-JLowProbableHigh

P2

L3

ERR04-JLowProbableMedium

P4

L3

ERR05-JLowUnlikelyMedium

P2

L3

ERR06-JLowUnlikelyHigh

P1

L3

ERR07-JLowLikelyMedium

P6

L2

ERR08-JMediumLikelyMedium

P12

L1

ERR09-JLowUnlikelyMedium

P2

L3

 

6 Comments

  1. Lothar Kimmeringer

    There should be another rule: Don't catch Throwable without checking for ThreadDeath. Here is a non-compliant code-example:

    try{
    untrustedClassInstance.callSomeMethod();
}
catch(Throwable t){
    logError("An error occured while calling some code by others", t);
}

    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:

    try{
    untrustedClassInstance.callSomeMethod();
}
catch(ThreadDeath td){
    throw td;
}

catch(Throwable t){
    logError("An error occured while calling some code by others", t);
}



    If the logging should take place all the time, the following alternative can be used:

    try{
    untrustedClassInstance.callSomeMethod();
}
catch(Throwable t){

    logError("An error occured while calling some code by others", t);
    if (t instanceof ThreadDeath){
        throw (ThreadDeath) t;
    }

}


    1. 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."

      • The stop method is deprecated and a guideline here will soon warn against using it. Unless you throw 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."

      • The compliant solution in this case will depend on whether the the cleanup is to be performed. 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."

      • This violates the rule that Errors should not be caught.
      • Catching 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 another ThreadDeath 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.

  2. 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.

  3. Jérôme GUY

    Hi

    I think we should have a similar rule of the ERR00-C.

    Don't you think ?


    1. 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.

      1. 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 (wink))

        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