[Soot-list] ThrowAnalysis

[John Jorgensen]

>>>>> "sunzzq" == Zhiqiang ZUO <sunzzq at gmail.com> writes:

    sunzzq> I have used mightThrow() in UnitThrowAnalysis
    sunzzq> to analyze which exceptions a jimple stmt may
    sunzzq> throw. For instance, InvokeStmt: virtualinvoke
    sunzzq> temp$4.<java.util.Vector: java.lang.Object
    sunzzq> elementAt(int)>(i);

    sunzzq> I found that the ThrowableSet returned contains all
    sunzzq> the Throwable exceptions. But in fact, this method
    sunzzq> call only throws the runtimeexception
    sunzzq> ArrayOutOfBoundsException, not any checked
    sunzzq> exceptions. So it seems that the result isn't
    sunzzq> accurate enough.

According to the JVM specification (section 4.7.4), the
requirements that a method throw only exceptions it has declared
in the method's exception_index_table (the bytecode equivalent of
Java's throws clause) "are not enforced in the Java virtual
machine; they are enforced only at compile time".  So even though
the API says java.util.Vector.elementAt() will only throw
ArrayOutOfBoundsException, a conservative analysis cannot rely on
that declaration without analyzing the contents of the method it
ends up being linked to.

UnitThrowAnalysis is only an intraprocedural analysis (as the
javadoc says "this analysis is based entirely on the opcode of
the unit, the types of its arguments, and the values of constant
arguments), so it has to pessimistically assume that any method
invoked might throw any exception whatsoever.

It would certainly be a valid exercise to create your own
implemenation of ThrowAnalysis with a less conservative analysis
which does trust throws declarations.  Without interprocedural
analysis, though, you'd still need to include all the subclasses
of RuntimeException and Error, since methods are allowed to throw
those without declaring them.  For that matter, there's at least
one RuntimeException (what if temp$4 in your example is null? A
NullPointer exception, that's what) and several linking Errors
(what if the runtime system can't find java.util.Vector?) which a
virtalinvoke has the potential to throw regardless of the method
being invoked.

There is excruciating detail about this (much of which I've
forgotten myself) in the technical report on the exception
analysis, http://www.sable.mcgill.ca/publications/techreports/sable-tr-2003-3.pdf
(probably mostly in section 2.3 and appendix A).

John Jorgensen