RFR(JDK11/NIO) 8205058 throw CharacterCodingException --> Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Joe Wang]

Thanks Lance!  Indeed it has been changed to CCE. I'm still 
familiarizing myself with IntelliJ. Opened it in NetBeans, it clearly 
indicates "missing @throws tag for " CCE, but I don't see anything like 
that in IntelliJ.

Updated webrev:
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev03/

-Joe

On 6/26/18, 11:24 AM, Lance Andersen wrote:
> Hi Joe,
>
> Should src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java
>
> —————
>      /**
>       * Constructs a new {@code String} by decoding the specified subarray of
>       * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>       *
>       * The caller of this method shall relinquish and transfer the ownership of
>       * the byte array to the callee since the later will not make a copy.
>       *
>       * @param bytes the byte array source
>       * @param cs the Charset
>       * @return the newly created string
>       * @throws IllegalArgumentException for malformed or unmappable bytes
>       */
>      String newStringNoRepl(byte[] bytes, Charset cs) throws CharacterCodingException;
>
> ————————
> include an @throws for CharacterCodingException?
>
>
>> On Jun 26, 2018, at 1:41 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>>
>>
>> On 6/26/18, 6:54 AM, Alan Bateman wrote:
>>> On 26/06/2018 05:50, Joe Wang wrote:
>>>> Hi Alan, Sherman,
>>>>
>>>> Here's a version where we, as Sherman suggested, throw an IAE with 
>>>> CCE as the cause. This approach reduces code duplication in SC, 
>>>> although it complicates the impl a little bit with the added 
>>>> parameter and the different behavior between the existing usages of 
>>>> the methods and the new ones. The existing code paths are kept 
>>>> intact so there's no compatibility issue for the existing code.
>>>>
>>>> This version also did not remove the try-catch in Files as Alan 
>>>> suggested earlier.
>>>>
>>>> http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev02/ 
>>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk11/8205058/webrev02/>
>>> This version looks much better. In StringCoding, do you really need 
>>> throwCCE? The encode/decode methods do a replace or throw so I 
>>> assume one flag will do. If combined with Sherman suggestion then it 
>>> would be minimal changes to StringCoding. It would be nice to get 
>>> rid of the IAE completely but that is for another day. In Files then 
>>> you don't need to check if cause is null before testing its type.
>>
>> Yes, combined with Sherman's suggestion eliminated the need for the 
>> new parameter. Here's the updated webrev:
>> http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev03/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk11/8205058/webrev03/>
>>>
>>> The update tests to check for UnmappedCharacterException and 
>>> MalformedInputException look good.
>>
>> Thanks,
>> Joe
>>
>>>
>>> -Alan
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180626/24d11e3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180626/24d11e3f/attachment-0001.gif>