Has it been considered to add a readKey() method to IO class? In my
experience, it is pretty commonly used by beginners when they write things
like console games (snake, catcher game etc.). I am aware there is
System.in.read() method, but since we decided to promote some methods to
separate methods in IO class, maybe readKey() or simple read() should also
be considered?
On Wed, May 8, 2024 at 4:16 PM Pavel Rappo <pra...@openjdk.org> wrote:
> On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>
> >> If we specify that, it would be very much unlike all other `Console`
> methods that are covered by this:
> >>
> >> * Unless otherwise specified, passing a {@code null} argument to
> any method
> >> * in this class will cause a {@link NullPointerException} to be
> thrown.
> >
> > I haven't given it a try, but a brief look at the code suggests that if
> the console implementation backed by JLine gets used, then a `null` prompt
> may not generate a `NullPointerException` (since JLine appears to allow
> `null`) whereas if the internal JDK console implementation gets used then a
> `NullPointerException` will get thrown. If the expectation is to disallow a
> `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand
> off to the underlying console implementations might be required.
>
> Good catch!
> `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)`
> does not throw `NullPointerException` (NPE), which it must. I'll fix the
> bug and add a test.
>
> Speaking of NPE. The newly added `Console.print` and `Console.println`
> methods do not throw NPE if passed null. While that's how it should be,
> they don't specify that, so the class-level NPE clause applies:
>
> * Unless otherwise specified, passing a {@code null} argument to any
> method
> * in this class will cause a {@link NullPointerException} to be thrown.
> ...
> public sealed class Console implements Flushable permits
> ProxyingConsole {
>
> I'll fix that.
>
> We should also specify NPE (or absence thereof) on methods of `IO`.
> Otherwise, this package clause applies:
>
> * Unless otherwise noted, passing a {@code null} argument to a
> constructor or
> * method in any class or interface in this package will cause a
> * {@code NullPointerException} to be thrown.
> ...
> package java.io;
>
> @stuart-marks speaking of exceptions. Do we need to add explicit `@throws`
> tag to `IO` methods?
>
> @throws {@code IOError} if {@code System.console()} returns {@code
> null}
>
> While it would make sense, it would also look superfluous: we already
> specify that error condition in the class comment and then in every
> method's main description. Do we need to add one more note on `IOError`?
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064
>
