Community
Participate
Working Groups
Why would we not issue warnings on the two lines called out ?? // --- public class NPEonCast { private static void occasionallyThrowException() throws Exception { if ((System.currentTimeMillis() & 1L) != 0L) throw new Exception(); } private static void open() throws Exception { occasionallyThrowException(); } private static void close() throws Exception { occasionallyThrowException(); } public static void main(String s[]) { Exception exc = null; if (exc == null) ; try { open(); // do more things } catch (Exception e) { if (exc == null) // no warning here ?? ; } finally { try { close(); } catch (Exception e) { if (exc == null) // No warning here ?? exc = e; } } } }
I'll take a fresh look for M7, thanks.
The fix reconciles concepts introduced in bug 345305 and bug 401088: Bug 345305 introduced FlowContext.markFinallyNullStatus(), mergeFinallyNullInfo(), conditionalLevel in order to feed null info (not def.assign) into the catch & finally blocks. Bug 401088 made sure this information is shared in nested try-finally structures. Unfortunately, real sharing of initsOnFinally caused undesired side effects. To fix this I replaced sharing of flowInfos with some new wiring of floxContexts using a new field outerTryContext. markFinallyNullStatus now delegates to the outerTryContext if set. To accommodate the new field outerTryContext and its evaluation a new class TryFlowContext has been fitted into the hierarchy above FinallyFlowContext and InsideSubRoutineFlowContext. I also had to fine tune when methods mergeFinallyNullInfo / markFinallyNullInfo would be effective: - don't record any initsOnFinally during analysis of the finally block itself (would otherwise appear to affect the catch blocks) - while analyzing catch blocks consider the null info as conditionally affecting the finally block
Verified for 4.3 M7 build id: I20130428-2000
