RFR: JDK-8346465 : Add a check in setData() to restrict the update of Built-In ICC_Profiles [v5]
Harshitha Onkar
honkar at openjdk.org
Mon Feb 24 19:14:53 UTC 2025
On Mon, 24 Feb 2025 17:09:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:
>>> > And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.
>>>
>>> That's demonstrably untrue. This method already has two.
>>
>> I was wrong here, the specification for [`ICC_Profile.html.setData`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/color/ICC_Profile.html#setData(int,byte[])) correctly displays the two entries for `IllegalArgumentException`. The generated javadoc for the proposed changeset contains three entries for IAE.
>>
>> I misremembered it, or it was a limitation in an IDE javadoc parser.
>
>> Regarding the scenario above, this apparent and has all been considered already and the IAE is the preferred solution.
>>
>> And FWIW I don't think ISE is really any better.
>
> <code>Illegal<i>Argument</i>Exception</code> implies the *argument* is invalid, but it is now thrown for a *valid* argument if the object *state* doesn't allow modifying the data.
>
> <code>Illegal<i>State</i>Exception</code> conveys the object *state* is inappropriate to call this method.
>
> There's a semantic difference between the two, and I think <code>Illegal<i>State</i>Exception</code> is better in this case.
>
> We can also discuss it with Joe in the CSR.
@aivanov-jdk As Phil mentioned earlier the already documented exception IAE for `.setData()` outweighs introducing a new exception. Using an existing exception would mean less disruption to any existing applications using the Java API.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968263836
More information about the client-libs-dev
mailing list