RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v3]

[Stuart Marks]

On Wed, 9 Apr 2025 10:36:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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.

Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)

People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,

    try (Scanner sc = new Scanner(System.in)) {
        String s = sc.nextLine();
    }

which is a mistake, but it takes a long time to explain....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035784546