[External] : Re: Error examples page

Ethan McCue ethan at mccue.dev
Sat Feb 4 03:48:03 UTC 2023


> IDEs have arguably more context to do it better, providing GUI support
for "suggestions" on how to change the code.

I've been thinking about this for a while and trying to zero in on
why the idea of leaving it to the IDE doesn't satisfy me.

I still struggle to put it into words, but I wanted to share (with
participants permission) an interaction I witnessed online that I think is
somewhat relevant.

-----


Student: Hello, I'm 16, and in AP computer science  in highschool.
Currently I have a repl.it project and have errors which I would appreciate
could be explained to me and help clarify the concepts if possible. Thank
you!
Student: I'm sry i am not very verse with code and am still trying to learn
and understand the error messages

./bank.java:101: error: class, interface, enum, or record expected
  double withdraw(){
  ^
./bank.java:103: error: class, interface, enum, or record expected
    double withdraw = 0;
    ^
./bank.java:104: error: class, interface, enum, or record expected
     double withdraw = scan.nextDouble();
     ^
./bank.java:105: error: class, interface, enum, or record expected
    while(withdraw >= 0){
    ^
./bank.java:108: error: class, interface, enum, or record expected
        withdraw = 0;
        ^
./bank.java:109: error: class, interface, enum, or record expected
      }
      ^
./bank.java:112: error: class, interface, enum, or record expected
          break;
          ^
./bank.java:113: error: class, interface, enum, or record expected
      }
      ^
./bank.java:116: error: class, interface, enum, or record expected
  }
  ^

Student: may i send you the assignment doc so you know what im trying to do?

Helper: would be helpful
Helper: also why not using an IDE for programming?

Student: im not sure what that is

Helper: Intellij or Eclipse etc?

Student: never heard of it. I use replit because its what my teacher tells
me to use

---------

In this there are two I think are of note

1. The error messages that the student got were not helpful for them seeing
their error. I don't have their original code so I can't dive in to why and
say "ah, we could obviously make this case better", but I choose to believe
there was some way to not vomit "class, interface, enum, or record
expected" nine times.

2. They are not using an IDE. They are using repl.it. This is really common
for early learners, as the hardware requirements of platforms like that are
lower and school systems will choose them for a myriad of reasons (cheaper
to buy chrome books, ability to share starter templates, etc.) Even *if*
IDEs are in a hypothetically better position to provide give corrective
feedback, they aren't always "in the room" for the sort of person that
needs it most.


On Thu, Nov 10, 2022 at 5:38 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Thanks for all the extra info.
>
> Yes, the desire for JLS references was primarily for some of the more
> obscure messages about generic types, and bounds checking, etc.
>
> Giving advice about how to fix code is definitely a challenge.  Bad or
> incorrect advice is arguably worse than no advice at all.   Generally, the
> policy for javac over the past few years has been to provide more specific
> details about what is wrong, and the general context of the error, but
> stopping short of suggesting changes.  IDEs have arguably more context to
> do it better, providing GUI support for "suggestions" on how to change the
> code.
>
> -- Jon
> On 11/10/22 2:21 PM, Ethan McCue wrote:
>
> I think for the JLS justification in particular - that is something which
> fits within the "info" part of our model but also isn't
> particularly interesting for the target audience of "people who trigger
> compiler errors."
>
>  A motivating example I sent to Vicente (almost 9 months ago! God I'm
> unproductive) was the contrast between the information conveyed in this
> message
>
>     import java.util.List;
>
>     enum Ex {
>         A,
>         B
>     }
>
>     public class MyClass {
>         public static void main(String args[]) {
>             var ex = B;
>         }
>     }
>
>
>
>     /MyClass.java:10: error: cannot find symbol
>             var ex = B;
>                      ^
>       symbol:   variable B
>       location: class MyClass
>
> As compared to that emitted by rustc
>
>     enum Ex {
>         A,
>         B
>     }
>
>     pub fn main() {
>         let ex = A;
>     }
>
>     error[E0425]: cannot find value `A` in this scope
>      --> src/main.rs:7:14
>       |
>     7 |     let ex = A;
>       |              ^ not found in this scope
>       |
>     help: consider importing this unit variant
>       |
>     1 | use crate::Ex::A;
>       |
>
>     For more information about this error, try `rustc --explain E0425`.
>
> Which could look like (ignoring the finer details of the ascii art)
>
>     error[E0123]: cannot find symbol `A` in this scope
>      --> src/Main.java:9:18
>       |
>     9 |     var ex = B;
>       |              ^ not found in this scope
>       |
>     help: consider importing this enum variant
>       |
>     1 | import static Ex.B;
>       |
>
>     For more information about this error, try `javac --explain E0123`.
>
> Where it is not enough to just "make a better message." There are
> structural deficiencies which preclude giving this sort of feedback.
>
> The *desire* to give a hint on how to fix something or extra context on
> why something is an error is what I think the true monster hiding under the
> bed of JDK-6397027 was. Language kinda has to be irregular in order to
> contain multiple of these semantic elements - y'know?
>
> (sorry if this isn't the most complete justification)
>
> ---
>
> My strategy for making progress has been to recruit the help of some
> students for whom working out a prototype is their senior design project.
> It's slow going, but we're all learning.
>
> On Thu, Nov 10, 2022, 4:40 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> Pithy instant response: it's not too big for mainstream rustc
>>
>>
>> On Thu, Nov 10, 2022, 4:31 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>>
>>> Our current brain scratcher is how to represent suggestions on how to
>>> fix code that actually "makes the correction for them"
>>>
>>> So like
>>>
>>>     int assert;
>>>
>>> How to model some code that can be later formatted as a suggestion to
>>> rename the "assert" variable to "assert_"
>>>
>>>
>>>
>>> While it sounds fun, it also sounds "too big" for mainstream javac.
>>> That suggests there could be a plugin mechanism to add more info to
>>> diagnostics.  Maybe.
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 11/10/22 11:42 AM, Ethan McCue wrote:
>>>
>>> Thanks - we have been tracking the PR. It will be helpful for us to
>>> track our progress.
>>>
>>> ---
>>>
>>> To springboard into something different but related:
>>>
>>> We have been working on modeling how to add kinds of information to
>>> JCDiagnostics that are semantically different from a message as produced by
>>> DiagnosticInfo.
>>>
>>> In the current hypothesis there are two new categories of information we
>>> are calling "help" and "info".
>>>
>>> "help" contains some suggestions on how to rectify a given sort of
>>> error. In the simplest form this is a codification of the "try using
>>> --enable-preview" type messages which exist somewhat ad-hoc throughout the
>>> codebase.
>>>
>>> Our current brain scratcher is how to represent suggestions on how to
>>> fix code that actually "makes the correction for them"
>>>
>>> So like
>>>
>>>     int assert;
>>>
>>> How to model some code that can be later formatted as a suggestion to
>>> rename the "assert" variable to "assert_"
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 10, 2022, 2:25 PM Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>> As a followup, the code to generate diags-examples.html needed some
>>>> TLC, and was fixed in JDK-8296137
>>>> <https://bugs.openjdk.org/browse/JDK-8296137>.
>>>>
>>>> The command to generate the report is effectively this:
>>>>
>>>> JAVA_HOME=$JDK $ANT \
>>>>     -Dlangtools.jdk.home=$JDK \
>>>>     -f make/langtools/diags-examples.xml
>>>>
>>>> where:
>>>>
>>>>    - the current directory is the root of the OpenJDK repo
>>>>    - ANT refers to a recent executable for Ant,
>>>>    - JDK refers to a build of JDK in the same repo containing the
>>>>    examples directory
>>>>
>>>> The report will be written to build/langtools/diags-examples/
>>>> -- Jon
>>>>
>>>> On 10/3/22 1:22 PM, Jonathan Gibbons wrote:
>>>>
>>>> It's generated by the code in open/test/langtools/tools/javac/diags/.
>>>>
>>>> There are various classes there, like RunExamples.java,
>>>> CheckExamples.java etc. You are probably looking for RunExamples.java;
>>>> there are comments in the code on how to use it.
>>>>
>>>> -- Jon
>>>> On 10/3/22 7:31 AM, Ethan McCue wrote:
>>>>
>>>> Hey all,
>>>>
>>>> My group stumbled upon this page with a bunch of error examples in a
>>>> nice presentable format.
>>>>
>>>> https://cr.openjdk.java.net/~jjg/diags-examples.html
>>>>
>>>> My suspicion is that this was generated by something in the codebase -
>>>> if so does anyone know the command of the top of their head?
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230203/34b548fd/attachment-0001.htm>


More information about the compiler-dev mailing list