Method Parameter Reflection spec

[Alex Buckley]

I have updated the 8misc.pdf spec with the conditions for throwing 
MalformedParametersException.

Hopefully this will be the last update of the spec before it is 
integrated into the JLS and JVMS as part of their updates for the Public 
Review of JSR 337 in October.

Alex

On 9/9/2013 1:15 PM, Alex Buckley wrote:
> On 9/9/2013 12:02 PM, Eric McCorkle wrote:
>> On 09/05/13 00:24, Joe Darcy wrote:
>>> I agree the sort of cases below due to corrupt / inconsistent class
>>> files are closer in flavor to error conditions than to exceptional ones.
>>> An end user program "shouldn't" have to worry about recovering from
>>> corrupt class files.
>>
>> Then it sounds like there's an agreement that the exception(s) should be
>> thrown from Executable.getParameters()  Good.
>>
>> What remains at this point is to determine what exceptions should be
>> thrown for what cases.  I don't really have a strong opinion on the
>> matter; I'll happily leave that up to someone else.
>
> First, we should stop using ReflectiveOperationException for
> reflection-time detection of malformed MethodParameters. While ROE
> itself is new, it represents the legacy checked exceptions from
> j.l.Class. For j.l.r.Parameter, it would be better to throw unchecked
> exceptions, in line with j.l.r.Field/Executable.
>
> Second, we all agree that the unchecked exceptions should be runtime
> exceptions rather than Errors. (When Joe said "closer in flavor to error
> conditions than to exceptional ones", I don't believe he intended "error
> conditions" to mean java.lang.Error. I think he meant "closer in flavor
> to problematic conditions than to truly exceptional, program-stopping
> ones.")
>
> I suggest MalformedParametersException, a subclass of RuntimeException,
> for cases (ii)-(vi). (Inspired by MalformedParameterizedTypeException.)
>
> Alex
>
>>>> Here's a list of all the ways MethodParameters attributes could go
>>>> wrong:
>>>>
>>>> (i) Actual length does not match attribute_length
>>>> (ii) The number of parameters (parameter_count) is wrong for the method
>>>> (iii) A constant pool index is out of bounds.
>>>> (iv) A constant pool index does not refer to a UTF-8 entry
>>>> (v) A parameter's name is "", or contains an illegal character [0]
>>>> (vi) The flags field contains an illegal flag (something other than
>>>> FINAL, SYNTHETIC, or MANDATED)
>>>>
>>>> (i) causes a ClassFileFormatError when parsing the class file (as it
>>>> should).  Right now, (iii) and (iv) cause an
>>>> IllegalArgumentException to
>>>> be thrown.
>>>>
>>>> I am working on a patch to correct the behavior for (ii)-(vi), so I can
>>>> have Executable.getParameters() throw whatever exception you choose
>>>> (ie.
>>>> this is one of those rare moments of freedom).
>>>>
>>>>
>>>> [0]: I seem to recall there being some discussion about backspaces, but
>>>> the current version doesn't seem to rule them out.  Has this been
>>>> changed?