[Soot-list] Reachability in CFGs

[John Jorgensen]

    irem> This I actually plan to solve the other way round. I
    irem> delete the exceptional edges that are not to handlers
    irem> contained in ExceptionalDests. And I plan to add edges
    irem> to handlers that are contained in the handlers of
    irem> ExceptionalDests if they are not already there. I think
    irem> this would solve the problem? Else, I end up with the
    irem> pedantic analysis which is not so informative for me.

    irem> So for this example:

    irem>   b = 0;          // point A
    irem>   try {
    irem>     b = a[i];     // point B
    irem>   } catch (IndexOutOfBoundsException e) {
    irem>     m3();         // point C
    irem>   }

    irem> I would add an edge from point B to C looking at the
    irem> handlers available for exceptions at point
    irem> B. Hopefully, they include point C.

The choice of throw analysis (--throw-analysis {pedantic|unit})
is independent of the choice whether or not to omit edges to
handlers from side-effect-less excepting units
(--omit-excepting-unit-edges).   --trim-cfgs just ties the two
(and -p jb.tt enabled:true) together to save some typing.

So I don't think you need to add edges to the handlers from the
excepting unit; if you don't omit-excepting-unit-edges, they
should be there already.

I've checked that for the example we've been talking about, the
options:

  --throw-analysis unit -p jb.tt enabled:true

will produce two edges to the handler, one from the instruction
that does the array indexing, and one from its predecessor.

(And you probably don't need "-p jb.tt enabled:true"; that's a
hack to reduce the likelihood that --trim-cfgs will cause Soot to
produce unverifiable bytecode, as a result of using a less
conservative model of exceptions than is employed by the VM's
bytecode verifier.)