Method Parameter Reflection spec

[Alex Buckley]

On 9/10/2013 5:04 PM, Joseph Darcy wrote:
> The conditions under discussion actually seem to me most like the
> conditions associated with true errors such as:
>
>      java.lang.AnnotationFormatError
>      java.lang.ClassFormatError (subclass of LinkageError)
>
> Whatever Throwable subtype we use for corrupt parameters information, it
> should certainly not be a checked exception. I think using a error as
> opposed to a runtime exception would be more consistent, but I'm willing
> to be convinced otherwise.

Sorry, I misunderstood your prior mail.

My skepticism about throwing an Error comes from the fact that using 
reflection to load a class causes ClassNotFoundException rather than 
NoClassDefFoundError. Similarly, using reflection to inspect a field 
causes NoSuchFieldException rather than NoSuchFieldError; and 
NoSuchMethodException rather than NoSuchMethodError for a method. That 
is, Errors come from the VM and Exceptions come from the Core Reflection 
API. An Error - especially from the VM! - means your program is dead in 
the water, but a client of the Core Reflection API should be able to 
handle a few little Exceptions because the members it thought were 
present are not.

(It's dumb that the Exceptions are checked, but that's orthogonal.)

This suggests throwing ClassFormatException (unchecked) when Core 
Reflection tries to read a malformed class file attribute. It's nothing 
like as serious as a LinkageError. A client of the Core Reflection API 
will simply act as if there are no annotations, parameters, whatever.

Then, dedicated Throwable subtypes for "Can't read 
RuntimeVisibleAnnotations attribute or its cpool entries" and "Can't 
read MethodParameters attribute or its cpool entries" would be unnecessary.

But I recognize that AnnotationFormatError may have set a precedent :-)

Alex