[Soot-list] exception handler lookup

[Greg Dennis]

Thanks so much for this. Very helpful, but I have a couple more questions.

The key documentation that seems to be lacking in the API is any
specification as to the order of the exception destinations in the
collection returned by getExceptionDests. For instance, it is not
clear from the API that the destination for one trap will always
precede the destination for an enclosing trap. Your sample code just
seems to presume this is the case.

Also, some of the exception destinations of a unit included in the
returned collection are actually for exceptions thrown by successor
units. Does the collection's iterator always return the destinations
for exceptions generated by the unit in question before the
destinations for succesor units?

Thanks,
Greg


On 3/15/06, John Jorgensen <jorgnsn at lcd.uregina.ca> wrote:
> >>>>> "gdennis" == Greg Dennis <gdennis at mit.edu> writes:
>
>     gdennis> Specifically, given a unit 'u' in a method 'm'
>     gdennis> and the runtime type of an exception 'e', I would
>     gdennis> like to know the handler unit in m that would that
>     gdennis> would be the successor of u if u throws e. If there
>     gdennis> is no such handler in m -- if m does not catch e at
>     gdennis> u -- I do *not* need to know the potential handlers
>     gdennis> in m's callers. Just a special unknown value in the
>     gdennis> latter case would do.
>
> There is support for this in the code that generates CFGs, though
> I don't remember the code well enough to give detailed
> step-by-step instructions (i.e. there are probably mistakes
> below, but the gist is right).
>
> Essentially, given a Body b for your method m:
>
>    ExceptionalUnitGraph g = new ExceptionalUnitGraph(b);
>    for (Iterator destIt = g.getExceptionDests(u); destIt.hasNext(); ) {
>      ExceptionalGraph.ExceptionDest dest =
>        (ExceptionalGraph.ExceptionDest) destIt.next();
>      Unit handlerStart = (Unit) dest.getHandlerNode();
>           // first unit in handler, null if exception escapes method
>      ThrowableSet throwables = dest.getThrowables();
>           // representation of the set of Throwable types caught
>           // by this handler
>      if (throwables.catchableAs(e)) {
>        // handlerStart catches e
>      }
>    }
>
> This is documented in the javadoc for
> soot.toolkits.graph.ExceptionalUnitGraph, with grimy details
> about how exceptional control flow is analyzed in
>
>   http://www.sable.mcgill.ca/publications/techreports/#report2003-3
>
> I looked at the source to src/soot/util/cfgcmd/CFGToDotGraph.java
> to remind myself how this works. CFGToDotGraph is part of the
> code which produces visualizations of CFGs using graphviz, and it
> probably provides the clearest example of the use of
> ExceptionDest (the other places within Soot which use
> ExceptionDest are the classes which actually generate CFGs,
> src/soot/toolkits/graph/{ExceptionalBlockGraph.java,ExceptionalUnitGraph.java}
> and src/soot/toolkits/exceptions/TraphTightener.java).
>
> If you have graphviz installed, it may be worthwhile generating a
> few visualizations using
>
>   java soot.tools.CFGViewer --soot-classpath  <soot-class-path> \
>      -f none --graph=ExceptionalUnitGraph --show-exception-dests \
>      --throw-analysis unit <analyzed-class-name>
>
> to generate dot files that provide visualizations of the
> ExceptionDests and the corresponding CFG edges (exception
> destinations and CFG edges are different: if u throws an
> exception that is caught by h, there will be CFG edges from the
> _predecessors_ of u to h; this is explained in the javadoc, in
> the technical report, and in a couple threads in the soot-list
> archives).
>
>