[Soot-list] ThrowableSet

[Eric Bodden]

Thanks for the detailed update, John.

Irem, in that case it would probably be easiest if you tried to figure
out what information exactly you want to extract and then have a look
at the implementation of ThrowableSet to see how to extract it.

Eric

On 02/11/2007, John Jorgensen <jorgnsn at lcd.uregina.ca> wrote:
> >>>>> "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.
>


-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada