Exceptions from invalid constant pool indices in the API

[-]

You are right. Making a ConstantPoolException also argues for making
an AttributeException, etc. which will explode the hierarchy with
little gain.

The real purpose of us is to not fail when we encounter an invalid
optional attribute in the class file; to detect how a failure happens
programmatically is a bit unrealistic, as we usually can't fix it
programmatically.

With this purpose in mind, your proposal of merging constant pool
index out of bounds exceptions into IAE or its subclasses is a right
step forward. I think whether we have a custom subclass of IAE depends
on if it makes catching errors in optional attribute definitions (say,
broken MethodParameters or RuntimeVisibleAnnotations that doesn't fail
execution in JVM unless inspected by reflection) easier.

Thanks,
Chen Liang

On Fri, Apr 14, 2023 at 10:42 AM Adam Sotona <adam.sotona at oracle.com> wrote:
>
> Throwing ConstantPoolException also for symbol conversions is another option. Classfile API have to catch all the IAEs whenever the conversion happen and wrap them to ConstantPoolException.
>
> There are actually approx. 30 places across Classfile API, where the conversions to symbols happen.
>
> Some of them are in constantpool package, however many symbol conversions are spread in methods across annotations, models, attribute infos and instructions.
>
> Should all of them wrap IAE and throw ConstantPoolException instead? For example for annotations the ClassDesc is constructed from class descriptor stored in Utf8Entry, so it is not technically a ConstantPoolException.
>
> On the other side if ClassEntry::asSymbol will throw ConstantPoolException and Annotation::classSymbol will throw IAE – that would be even more confusing.
>
>
>
> I think it is a bit overkill for the very specific use case in javap and I’m not sure it is worth the price.
>
> I propose to unify on IAE (for simplicity in major use cases) and possible refine on ConstantPoolException (or more) as sub-class(es) of IAE (for the specific cases where we might want to differentiate).
>
>
>
> Thanks,
>
> Adam
>
>
>
>
>
>
>
> From: liangchenblue at gmail.com <liangchenblue at gmail.com>
> Date: Thursday, 13 April 2023 19:53
> To: Adam Sotona <adam.sotona at oracle.com>
> Cc: Brian Goetz <brian.goetz at oracle.com>, classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
> Subject: Re: Exceptions from invalid constant pool indices in the API
>
> In your example, I don't think that would constitute a valid class
> constant pool entry: per JVMS 4.4.1
> https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.4.1,
> the CONSTANT_Class_info is not valid without a valid Utf8 entry
> content. I think the 3rd case is essentially the same as the 2nd case
> you've listed, and they can both be converted from
> IllegalArgumentException to ConstantPoolException, as they fall in the
> same error category (invalid name_index) under the VM spec. They can
> just be distinguished by different messages.
>
> On Thu, Apr 13, 2023 at 11:18 AM Adam Sotona <adam.sotona at oracle.com> wrote:
> >
> > By failing symbols validation I mean when for example index points to correct ClassEntry pointing to correct Utf8Entry name, however the name is not valid class name and ClassDesc construction throws IAE.
> >
> > Each such case must be individually safeguarded to do not prematurely terminate the whole javap.
> >
> >
> >
> > From: Brian Goetz <brian.goetz at oracle.com>
> > Date: Thursday, 13 April 2023 17:46
> > To: Adam Sotona <adam.sotona at oracle.com>
> > Cc: liangchenblue at gmail.com <liangchenblue at gmail.com>, classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
> > Subject: Re: Exceptions from invalid constant pool indices in the API
> >
> > So, I think there are two reasons we might consider a more precise exception here.  One is Chen’s concern of “what do I catch”, and the other is simply getting a more human-readable explanation of what went wrong.  Exceptions like AIOOBE and IAE are often not helpful in explaining what actually went wrong (what index? Into what? Where did the bad value come from?).
> >
> >
> >
> > Part of this is the exception type (which helps both of these audiences), and part of this is the exception message (which helps only the latter.).  We should probably do a pass and make sure we have informative error text in all throw points.
> >
> >
> >
> > What do you mean “when the symbol fails validation”?
> >
> >
> >
> > On Apr 13, 2023, at 9:00 AM, Adam Sotona <adam.sotona at oracle.com> wrote:
> >
> >
> >
> > I’ve tried to convert all CP related exceptions to a new ConstantPoolException, however IllegalArgumentException is still in the game  (in javap) as a secondary exception thrown during validation of symbols.
> >
> > For example printing of Signature attribute or any ClassDesc can now fail with:
> >
> > IndexOutOfBoundsException when the index is invalid
> > IllegalArgumentException when the CP entry is invalid
> > IllegalArgumentException when the symbol is invalid
> >
> >
> >
> > After merge of CP-related IndexOutOfBoundsException and IllegalArgumentException into ConstantPoolException we can get:
> >
> > ConstantPoolException when the index is invalid
> > ConstantPoolException when the CP entry is invalid
> > IllegalArgumentException when the symbol fails validation
> >
> >
> >
> > Is it still worth to introduce a new exception when javap still must individually safeguard also IllegalArgumentExceptions ?
> >
> >
> >
> > What about to replace CP-relate IndexOutOfBoundsException with IllegalArgumentException so we will have one single type of exception to catch when class reading?
> >
> > Or what if we make ConstantPoolException a sub-class of IllegalArgumentException?
> >
> >
> >
> > Thanks,
> >
> > Adam
> >
> >
> >
> > From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Brian Goetz <brian.goetz at oracle.com>
> > Date: Tuesday, 11 April 2023 2:15
> > To: liangchenblue at gmail.com <liangchenblue at gmail.com>
> > Cc: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
> > Subject: Re: Exceptions from invalid constant pool indices in the API
> >
> > Good suggestion!
> >
> > > On Apr 10, 2023, at 4:34 PM, liangchenblue at gmail.com wrote:
> > >
> > > When I was taking a peek at the conversion of javap to Classfile API,
> > > I found that the old API has a feature that the API might be
> > > interested in: a dedicated exception ConstantPoolException for invalid
> > > constant pool indices, caused by incorrect types or out-of-bounds. We
> > > currently throw IllegalArgumentException and IndexOutOfBoundsException
> > > in the Classfile API, so it is a bit harder to catch such invalid
> > > indices.
> > >
> > > Javap is tolerant to invalid class file formats while the reading part
> > > of Classfile API is not so much; in general, Classfile API fails fast
> > > if it encounters invalid constant pool entries; this I agree, that
> > > invalid entries render a classfile invalid, but maybe we can unify the
> > > reading exceptions from ConstantPoolReader into a common type like in
> > > the old API, so we can more easily report constant pool errors or skip
> > > invalid but optional entries.
> > >
> > > Chen Liang
> >
> >