Sorry I was obviously missing the part of this thread where it was
decided to not actually fix this as requested in the bug due to
compatibility issues.
I agree with Brian that something must be added to the class-level
javadoc explaining that due to a historical oversight there is one
method that declares it throws IOException (and can actually throw it?).
I don't see why that method couldn't still honour the checkError
protocol as well though.
David
On 24/07/2019 11:31 am, David Holmes wrote:
Jumping in here as this change is starting to really confuse me ...
On 24/07/2019 2:41 am, Brian Burkhalter wrote:
On Jul 23, 2019, at 8:27 AM, Brian Burkhalter
<brian.burkhal...@oracle.com> wrote:
On Jul 23, 2019, at 8:20 AM, Alan Bateman <alan.bate...@oracle.com
<mailto:alan.bate...@oracle.com>> wrote:
On 23/07/2019 16:08, Brian Burkhalter wrote:
I don’t see what you mean.
@Override
public void write(byte buf[]) throws IOException {
super.write(buf);
}
Should “trouble” be set and the IOE re-thrown?
super.write(byte[]) will invoke PrintStream overrides write(byte[],
int, int) so IOE won't be thrown (and why the proposed change to the
class description isn't right). The method description is probably
the best place to describe the behavior.
Here is an update which accounts for the foregoing comments.
http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/
609 @Override
610 public void write(byte buf[]) throws IOException {
611 super.write(buf, 0, buf.length);
612 }
This is wrong! The whole point of this bug is to ensure that PrintStream
methods honour its contract of NEVER throwing IOException. I mean that
is what the bug synopsis and description are all about!
David
-----
Thanks,
Brian
