On Mon, 21 Jul 2025 12:19:11 GMT, Volkan Yazici <vyaz...@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`.)
>
> src/java.base/share/classes/java/lang/String.java line 1262:
> 
>> 1260:         MalformedInputException mie = new MalformedInputException(nb);
>> 1261:         String msg = "malformed input off : " + off + ", length : " + 
>> nb;
>> 1262:         mie.initCause(new IllegalArgumentException(msg));
> 
> Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing 
> _extra diagnostics information_ and wrapping a `CCE` as a cause. After 
> switching methods to throw `CCE`, which doesn't have a ctor accepting a 
> `String` message, to retain this extra diagnostics information, I've added 
> swapped their causal chain placement, and wrapped `IAE` with a `CCE` this 
> time.
> 
> This played well with `CCE`-throwing methods, yet there are other `public` 
> methods which did not have `throws CCE` in their footprint. For backward 
> compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` 
> wrapping the `CCE`, which matched the old behavior.

Introducing CCE (an IOException) into more places in string handling is going 
in the wrong direction.
As declared exceptions, they have to be caught and handled or re-thrown. That 
makes the source more complex and harder to maintain, as seen in the cce2iae 
mechanism.
The prior use of IAE encapsulating a CCE as needed is simpler and more 
consistent with other Runtime exception handling in most of the String class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2240031460

Reply via email to