jorgnsn at lcd.uregina.ca
Fri Nov 2 12:37:23 EDT 2007
>>>>> "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>
irem> Is there a clean way to get an enumeration of the
irem> exception types included in a particular ThrowableSet?
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
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
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
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.
More information about the Soot-list