On Tue, 29 Jul 2025 13:25:14 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> `NoRepl`-suffixed `String` methods denote methods that do not replace
>> invalid characters, but throw `CharacterCodingException` on encounter. This
>> behavior cannot easily be derived from the method footprints, has been a
>> source of confusion for maintainers, and is not uniformly adopted, e.g.,
>> `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`.
>> This PR removes `NoRepl` suffix from method names and consistently uses
>> `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> If CCE should have a constructor with a message, it can be added if you have
> a clear idea how it would be used.
Motivated by @RogerRiggs inquiries, and @AlanBateman's below remark,
> Another high level comment from a first read is that it feels like there are
> two forms needed. One form is REPLACE action and doesn't throw. The other is
> REPORT action and throws CharacterCodingException.
grouped `String` methods by `doReplace` argument in 1fb8582e3f9. There are
several `String` methods of the following form:
private static byte[] encode8859_1(..., boolean doReplace) {
// ...
if (!doReplace) {
throwUnmappable(sp);
}
// ...
}
We want to make `doReplace = false` case visible in the function footprint, and
this resulted in:
private static byte[] encode8859_1(..., boolean doReplace) throws CCE { ...
}
Though this propagates the checked `CCE` even for `doReplace = true`. To avoid
this, I've grouped methods by `doReplace` argument into two:
private static byte[] encode8859_1(...) { ... }
private static byte[] encode8859_1NoReplacement(...) throws CCE { ... }
As a result,
1. `doReplace = true` call-sites invoke `encode8859_1()`, replacement *will*
occur, and there is no checked `CCE` thrown
2. `doReplace = false` call-sites invoke `encode8859_1NoReplacement()`,
replacement will *not* occur, and `CCE` needs to be handled
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3167985180
