Exceptions from invalid constant pool indices in the API

[Adam Sotona]

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<mailto: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<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>>
Date: Tuesday, 11 April 2023 2:15
To: liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Cc: classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org> <classfile-api-dev at openjdk.org<mailto: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<mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230413/6702e27f/attachment-0001.htm>