Inconsistencies when creating a Reader from a Path

[Alan Bateman]

On 27/02/2020 19:33, Norbert Kiesel wrote:
> :
>
> Which brings me to my questions:
>
>   1. Should the 2 approaches not behave identical by default?
>   2. Is there a way to use the first approach but end up with the same error
> behavior as the second approach? One possible way would be to create an
>      overloaded `Files.newBufferedReader` which takes a `CharsetDecoder` as
> second parameter.
The java.io APIs mostly date from early JDK releases. Changing 
InputStreamReader to report errors with malformed input or unmappable 
characters would be an incompatible change. Yes, replacing erroneous 
input with a replacement value can be surprising in some usages. I think 
we should at least improve the documentation of the APIs that bridge 
between byte and character streams. The Files.newBufferedReader factory 
method was intended to avoid surprises. It uses UTF-8 by default (not 
the default charset) and is specified to return a Reader that throws 
when malformed input or unmappable is encountered. Yes, a variant that 
takes a CharsetDecoder could be added but that is an advanced API so the 
method would only save one line of code for someone that has a 
CharsetDecoder. Best to follow up on core-libs-dev, I think we should at 
least improve the javadoc in a number of places.

-Alan