Re: how to handle throws declarations with duplicate exceptions

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

Soot already produces bytecode that is far from identical to its input,
and I can't see any effect of removing duplicate exception declarations
on the semantics. Therefore, I see no reason for Soot to preserve
duplicate exceptions.

The way I see it, there are two options.
1) remove the throw RuntimeException from addExcetption(). Soot will
then silently ignore addition of duplicate exceptions.
OR
2) modify coffi to say:
if( !method.throwsException(e) ) {
    method.addException(e);
}

Now, Soot's interfaces are generally written in a very defensive and verbose
style (eg. one has to ask whether a class hasSuperclass() before doing a
getSuperclass(), rather than just doing the getSuperclass() and checking
for null). To remain consistent with this style, the second option is
preferable. However, I personally find this style overly verbose in some
cases, so I will not argue against 1).

Ondrej

On Thu, Jan 23, 2003 at 05:16:08PM -0500, John Jorgensen wrote:
> This note seeks input on the best approach to take to fixing a
> minor bug in Soot.
> 
> As a result of a bug report, I have just learned that javac (and
> jikes) both accept methods with "throws" declarations that
> include the same exception more than once, as in this example:
> 
>   public static int 
>   method(int i) throws IllegalArgumentException, IllegalArgumentException {
> 
> Moreover, the compilers generate class files with an Exceptions
> attribute which also contains multiple copies of the declared
> exception (i.e., "javap -c" on the output class file will still
> show you "throws IllegalArgumentException, IllegalArgumentException").
> 
> But soot.SootMethod.addException() refuses to add multiple copies
> of the same exception to the "throws" declaration of a given
> method. It throws a RuntimeException instead:
> 
>     public void addException(SootClass e) 
>     {
>         if (exceptions == null)
>             exceptions = new ArrayList();
>         else if (exceptions.contains(e))
>             throw new RuntimeException("already throws exception "+e.getName());
> 
>         exceptions.add(e);
>     }
> 
> This seems unacceptable since it prevents Soot from reading some
> class files produced by the standard tools for compiling Java.
> The question is how to fix the problem.
> 
> I imagine that the original author of addException() included the
> check to ensure that people using Soot to modify class files
> could not inadvertently add multiple declarations of the same
> exception, probably never suspecting that a class file might
> include attributes with multiple copies of a single exception even
> before its file was read into Soot.  
> 
> This suggests that we might want to continue to provide some kind
> of duplication exception from addException(), without preventing
> the input of class files whose Exceptions attributes already
> contain duplicate entries (probably by catching and discarding
> the duplication exception in the Coffi routines that read class
> files).
> 
> A simpler alternative would be for addException() to simply
> ignore requests to add an exception that is already included. In
> this case we could stop throwing the exception---since adding
> duplicates would have no effect---but the output Exception
> attributes would differ from the input, lacking the duplicate
> declarations. Would that matter?  Can anybody think of
> circumstances where multiple copies of the same exception in the
> Exceptions attribute means something different than a single
> copy?
> 
> In principle there are two orthogonal issues:
> 
>    - whether to include multiple copies of an exception
>      in the Exceptions attribute, rather than simply ignore
>      repeated additions of the same exception.
> 
>    - whether or not to warn addException()'s caller when it requests
>      the addition of an exception that is already included.
> 
> and thus four possible solutions:
> 
> 1. Add duplicates and throw an exception (which coffi would
>    ignore).
> 
> 2. Add duplicates and don't throw an exception.
> 
> 3. Don't add duplicates and throw an exception.
> 
> 4. Don't add duplicates and don't throw an exception.
> 
> 
> My preference is for option 4, since it is the simplest, with 1
> as my second choice. (In the case of option 1, I would also
> change the duplicate exception to IllegalArgumentException, since
> that more accurately reflects the error condition, yet does not
> requiring existing callers of addException() to change their own
> "throws" declaration).
> 
> The only objection I can imagine to option 4 would be if there is
> some significance to multiple copies of a single exception in an
> Exceptions attribute.  So does anybody know of any such
> significance?
> 
> Thanks.
> 
> -- 
> John Jorgensen		jjorge1@cs.mcgill.ca