On Mon, 7 Apr 2025 09:18:37 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> This implementation is not to be emulated by beginners. If an Exception.is >> thrown here, a user might be tempted to add handlers in their code, while >> this is an issue with the setup. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031782109
