On Mon, 7 Apr 2025 18:28:21 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>> Someone is bound to ask why the readln method throw but the println methods >> don't. > > The IOError was carried over from Console.readLine(), which throws IOError on > error. Of course we're decoupled from Console now, but that was the original > reason. > > My guess is that Console methods throw IOError because (a) they didn't want > to make everybody catch IOException, (b) they didn't want to maintain an > internal error state like PrintStream, and (c) they wanted to throw a > throwable whose type conveyed the meaning that it wasn't expected to be > handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning > still applies here. > > UncheckedIOException wasn't added until JDK 1.8. Note also that > UncheckedIOException has a cause of IOException, so it can't arise from some > other throwable. This was used in the previous implementation, where IOError > was thrown if Console was null. That doesn't apply anymore, but IOError is > still somewhat more flexible than UncheckedIOException in this regard. > > I think we need to say something, implicitly or explicitly, about error > handling. Note that PrintStream has this internal error state so output is > covered already. For input it seems like IOError is reasonable, but maybe > there's a better choice. The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause. System.in.close() would a be wild thing to do, but a case where readln would throw IOError. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035089368
