On Wed, 8 May 2024 18:25:50 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
>> Most of these are defined in terms of `String.valueOf(Object)` which if
>> passed a null reference will return the String object containing `null`. So
>> no, I don't think NPE should be thrown. It might be worth mentioning this
>> explicitly somewhere though.
>
>> Most of these are defined in terms of `String.valueOf(Object)` which if
>> passed a null reference will return the String object containing `null`. So
>> no, I don't think NPE should be thrown. It might be worth mentioning this
>> explicitly somewhere though.
>
> Right, in our current model, `Console.readln(prompt)` can be reduced to
> `Console.print(prompt)` followed by actual reading. `Console.print(prompt)`
> can in turn be reduced to printing the result of `String.valueOf((Object)
> prompt)`, which is a string "null".
>
> The above reduction means that `Console.readln(null)` will not throw NPE.
> Now, what I'm asking if that's what we really want.
>
> With `Console.println(null)` and `Console.print(null)` not throwing NPE makes
> sense. However, with `Console.readln(null)` it might not. After all, we ask
> for a **`String`** prompt, not an `Object` prompt. All other methods of
> `Console` that accept `String`, throw NPE if that string is null.
>
> One more consideration. Whatever the behaviour we choose for
> `Console.readln(null)`, we should choose the same behaviour for
> `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly
> surprising inconsistency.
>
> Thoughts?
A fair question, whether to treat `readln` differently because it takes a
String argument instead of an Object.
I guess I'd like to see a scheme like the following:
String s = cons.readln(prompt);
is effectively the same as
cons.print(prompt);
cons.flush();
String s = cons.readLine(); // note no-arg readLine() method
In other words, define `readln` to behave "as if" the other methods were
called. This would end up with a null prompt argument printing "null" and not
throwing NPE.
This is internally consistent, at least. Beginning programmers will eventually
learn that using null will lead to NPE. It might make things easier if NPEs
were kept out of this little corner of the library. That's just my guess though.
Also, recall that `String.valueOf((Object) null)` and `String.valueOf((String)
null)` both result in "null". But if one were to write `String.valueOf(null)`
that throws NPE, because that selects the `valueOf(char[])` overload. That's
kind of the outlier. Note further that the built-in `+` string concatenation
operator will also convert null references to "null".
Personally I've always hated that string conversions of null in Java often
result in "null" but it's baked into the system fairly deeply, so I think we
should stick with it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594542505
