Instructions:

Group work Continue working with your partner from JavaEyes, Part 2. But switch roles so that the other person does the JCreator typing in this part.

Final report When you see a question prefaced by     Question: blah blah blah ... put your answer in your final report.

Time limit Most students complete this exercise in 30 to 60 minutes. If you find yourself spending much more time than that on this exercise, please see your instructor.

Question: What time is it now? (Later we will ask you how long you spent on Part 3 of JavaEyes.)

Kinds of Errors

Programs can have two kinds of errors:

• Compile-time errors are errors that the compiler finds when you compile the program. These are also called syntax errors because they are errors in the syntax, or notation, of the program.

  Programming languages require you to be precise. So, for example, if you type Colr or even color where Color is required, that is a syntax error. Likewise, omitting an expression where it is required and referring to something that is not in the program are syntax errors.

• Run-time errors are errors that are not detected until you run the program. For example, the program might do the wrong thing or even crash in some circumstances. Run-time errors occur when you write code that is legal but does not result in the behavior that was specified.

This exercise focuses on compile-time errors, because those are what you will first encounter. But don't think that a program is correct merely because it compiles. It must compile and behave as specified to be correct.

Fixing Compile-Time Errors

1. What happens when things go wrong with your project? To find out, you're going to comment out a portion of the code, in order to see what kinds of compile-time errors you can get.

   A comment is an area in your code file that is deliberately ignored by the compiler. Programmers put comments in their code to help themselves and others understand their code. (More on this in Part 4 of JavaEyes.)

   To comment out a portion of code means to change the code into a comment (so that the compiler then ignores it). This is sometimes useful as a error-finding technique (it simplifies the code), but today we'll use commenting-out simply as an easy way to introduce errors (so that you can gain experience with error messages).

   In Java, you use the following scheme to comment your code:

       /* This is a comment. */
       
       // This is also a comment.
       
       /* This
        * is
        * also
        * a comment.
        */ 
        
        // This
           is
           not
           a 
           comment (and will produce an error).
   

   Anything found within the delimiters /* and */ is considered a comment. This does not mean that you can "nest" comments! In other words,

   /* left /* inside */ right */
   

   would not be a legal comment. The compiler would consider

   /* left /* inside */
   

   a comment, and it wouldn't know what to do with the final */.

   Any text which comes after // on the same line is also considered a comment. Text which comes after // on a subsequent line is no longer considered commented (unless of course, it has been commented somewhere else).

   Question: Write a two-line comment that states the color of your partner's eyes:

   • Using the /*   */ notation.
   • Using the // notation.

   If you have further questions about comments, please ask a course assistant.

2. Open JCreator so that you are back in your JavaEyes project.

3. Compile and run JavaEyes to confirm that you are starting with an uncorrupted copy.
   • If you get any error messages, get help now.

4. Find the line in the JavaEyes.java file that says:

        Eye eye1; 
   

   Change the word Eye to EYE; that is, change it to all upper-case letters like this:

        EYE eye1; 
   

   Compile again and see what happens.

   It should not compile successfully this time. (Case matters!)

   Question: When you changed Eye to EYE:

   • How many errors did the compiler report? (Hint: look at the bottom of the bottom panel.)
   • What is the error message? (Hint: it is 3 words.)
   • To what line does the error message refer?
   • What symbol does the compiler use to indicate what word on that line it views as the source of the error?

   If you have any doubts about your answers to the above, simply ask a neighbor or assistant.

5. Double-click on the line that contains the error message (or you can use the F4 key as a shortcut to the next error).
   • That should bring you directly to the line that the compiler identifies as the source of the error (indicated by a little arrow in the left margin).
   • If it doesn't, get help now.

   Deciphering compile-time error messages is an art that simply requires experience. The error message that you just received -- cannot resolve symbol -- is one of the most common. It can occur for many reasons, including:

   • You misspelled the symbol that the caret (^) points to.
   • You spelled that symbol one way in part of your program and another way elsewhere.
   • You forgot to declare the symbol, or declared it in the wrong place.
   • The symbol is part of a library and you forgot to import the library.

6. Now insert two slash characters (//) at the beginning of the same line to comment it out, so that it looks like:

        // EYE eye1; 
   

   (Do not delete the line; you'll need it later.) Compile again and see what happens.

   Again, it should not compile successfully. But now the compiler reports more than one error, at lines that you did not touch!

   Question: When you commented out the line, making it // private EYE eye1; :

   • How many errors did the compiler report?
   • What is the first error message?
   • To what line does the first error message refer?
   • What symbol does the compiler use to indicate what word on that line it views as the source of the error?

   These examples show that:

   • Sometimes the compiler takes you to the line on which you made the error.
     • As in the first example (changing Eye to EYE).
   • Sometimes the real source of the error is far removed from the lines to which the compiler directs your attention.
     • As in the second example (commenting out the line).

   With practice, you will soon be able to use the (sometimes cryptic) compiler messages to locate the real source of compile-time errors.

7. Before you repair the error, run the application again.
   • You'll see that it runs fine.
   • That's because when the Java compiler cannot complete its work, as in this case, the file JavaEyes.class that the compiler creates remains unchanged.
   • So when you run a Java program after an unsuccessful compile, you are really running the last version that compiled successfully. (Here, that's the version before you messed with things.)

8. Take out the backslashes you inserted, change the spelling from EYE back to Eye), and reassure yourself that the program again compiles successfully.

9. Now find the line that says:

        public JavaEyes() {
   

   and comment it out. Compile. Your error window should now display many error messages!

   Take a look at them and see if you can understand some of them. Also try double-clicking on some of them to see where the compiler thinks you have made errors. It seems that many of these error messages don't relate directly to the error we actually committed!

   • This raises an important point: the compiler simply flags the lines that are illegal; the real source of the error(s) may be far removed.
   • So if the compiler tells you that you committed a bunch of errors, it is quite possible that there is one simple source that will fix them all!

10. Fix the code you just broke, and recompile to make sure everything works again.

Fixing Run-Time Errors

1. The previous section showed you compile-time errors. Now let's look at run-time errors.

   To do so, run JavaEyes and move the mouse all around the gray frame. Eventually you should see an error message in the bottom panel that begins:

        java.lang.ArithmeticException: / by zero
   

   • This is a run-time error because it occurs when the program is run, not when you compile it.
   • The source of the error is unimportant to us today. (I introduced the error on purpose.)

2. There is at least one other run-time error, it seems to me. See if you can spot it:
   • Hint: this is an error in the design, so you will not see any error message -- just "wrong" behavior.
   • If you don't spot anything within a minute, simply ask a neighbor or assistant.

   Question: Briefly describe the run-time error you found (the "other" one, not the "/ by zero").

Getting Help

One of the things we hope that you will take away from this class is that you will be a more productive (and happy!) software engineer if you learn to work in groups. If you have a question, ask your classmates! This helps both of you: it clears up your question, and reinforces another student's understanding of the material. The course assistants are also a good resource, and you should feel completely at ease with asking them for help. That's what they are there for, and you want them to feel needed, don't you?

Summary and Finishing Up

1. Question: Programs can have two kinds of error. What are they?

2. Question: When you get a compile-time error message, how do you go to the line that the compiler thinks is the source of the error?

3. Question: Does the compiler identify the correct source of the error: never? sometimes? always?

4. Compare your answers with what others say. Keep asking other people (or assistants!) until you are confident that you know the right answers.

5. Question: How much time did you spend on Part 3 of JavaEyes?