[Soot-list] ThrowableSet

[John Jorgensen]

>>>>> "eric.bodden" == Eric Bodden writes:

    eric.bodden> Hmm, from what I can see right now, it does not
    eric.bodden> actually seem like it (very strange, though). I
    eric.bodden> could make it implement the Iterable interface
    eric.bodden> in the SVN trunk, if you like.

    eric.bodden> On 02/11/2007, Irem Aktug <irem>
    eric.bodden> wrote:
    irem> 
    irem> Is there a clean way to get an enumeration of the
    irem> exception types included in a particular ThrowableSet?
    irem> 

This is not as straightforward as it might appear, and exposes an
open question from the project which produced ThrowableSet.

I had to look at section 3.3.2 of the technical report
(http://www.sable.mcgill.ca/publications/techreports/sable-tr-2003-3.pdf)
myself to remind myself of the details, so I probably don't have
all of them right.

I can think of two things you might be looking for when asking to
enumerate exception types in a particular ThrowableSet:

 a) Probably you want a set of the individual exception types
    (as they would appear at the level of Java code) represented
    by the ThrowableSet: e.g.

      ArrayIndexOutOfBoundsException, IndexOutOfBoundsException  ...

    That's the possibility which is not straightforward, since
    ThrowableSet contains no such set.  Java's libraries define
    hundreds of exception types, and the code Soot analyzes might
    well define new exception types of its own.  Without
    knowing what the total universe of Throwable types is,
    ThrowableSet cannot represent the set of exceptions caught by

       catch (Throwable t)

    by an enumeration of all the exception types that might be
    caught, since it cannot know what all the subtypes of t are.

    Instead ThrowableSet contains two set of RefType objects.
    Each of these objects represents either an individual 
    exception type, or a type and all its subtypes.  One of the
    two sets represents types included by the ThrowableSet, and the
    other represents types excluded by the ThrowableSet.  That
    lets a ThrowableSet represent things like

      All subtypes of Error and all subtypes of RuntimeException,
      except for subtypes of IndexOutOfBoundsException

    without having to know ahead of time all the individual
    Throwable types that might fit that description.

    (There are limitations on the combinations of inclusions and
    exclusions possible (that's the unresolved open question),
    due to my inability to think of a representation for these
    "type hierarchies with holes in them" which would allow for
    arbitrary addition and removal operations.  Essentially the
    limitations insist that all additions to a set precede any
    removals, which still allows for creating ExceptionalUnitGraphs
    ---first you add all in all the exceptions that a Unit might
    throw, then you remove the exceptions caught by applicable
    handlers.)

    So with only the information in the ThrowableSet data
    structures, there is no way to enumerate the individual types
    represented by a ThrowableSet. 

    Client code that knows the universe of exception types it is
    interested in, though, could pass each of those exception
    types to ThrowableSet.catchableAs() in turn, and build a
    subset of consisting of the types of interest for which the
    returned value is true.  If such an operation is thought to
    be of frequent value, perhaps it should be added to
    ThrowableSet's interface as a convenience method, but it
    wouldn't allow client code to do anything new that it can't
    already accomplish.

 b) Maybe you already know what I said in possibility a), and you
    what you want is an enumeration of the two lists of RefType
    objects representing the ThrowableSet, so you can analyze
    them on your own.

    I don't think that we should make these sets part of the
    official public interface of ThrowableSet; understanding
    what they mean requires knowledge of how ThrowableSet is
    implemented, and that implementation could conceivably
    change, should anybody figure out how to do the things I
    couldn't figure out. 

    So if you need access to the representation, I think you
    should make your own replacement of ThrowableSet, where you
    do something like making exceptionsIncluded and
    exceptionsExcluded package-private, rather than private. Then
    add your exception-inspection code to a new class in the
    soot.toolkits.exceptions package.  Or simply put your code
    into your copy of ThrowableSet, with a view to eventually
    submitting your version for inclusion in Soot, since in this
    case you're likely exploring things which would represent
    improvements to the current implementation.