JDK-8205058 : (fs) Files read/writeString should throw CharacterCodingException instead of IOException with an IllegalArgumentException as cause
- Type: Bug
- Component: core-libs
- Sub-Component: java.nio
- Affected Version: 11
- Priority: P3
- Status: Closed
- Resolution: Fixed
- Submitted: 2018-06-14
- Updated: 2018-07-07
- Resolved: 2018-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 11 | JDK 12 |
|---|---|
11 b20Fixed  |
12Fixed |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
Files read/writeString implementation could be cleaner if it throws CharacterCodingException instead of an IOException with an IllegalArgumentException as cause for the malformed or unmappable cases. The code can be cleaner with an import of jdk.internal.misc.JavaLangAccess rather than repeating the fully qualified class name. The definition of JLA can be moved up to the top. There's also a few inconsistencies with the existing code that would be good to fix (indenting and line length issues mostly). The test looks reasonable. In getData() then then "shouldn't happen" case should throw an exception as a NPE here might be tricky to diagnose there. Another nit is the sb field - can that be removed.