Name:
(as it would appear on official course roster)
Umail address:	@umail.ucsb.edu	section 9am or 10:30am
Optional: name you wish to be called if different from name above.
Optional: name of "homework buddy" (leaving this blank signifies "I worked alone"

h10: Review from Livecoded Parser Session

ready?	assigned	due	points
true	Thu 07/14 09:00AM	Tue 07/19 09:30AM

You may collaborate on this homework with AT MOST one person, an optional "homework buddy".

MAY ONLY BE TURNED IN IN THE LECTURE/LAB LISTED ABOVE AS THE DUE DATE,
OR IF APPLICABLE, SUBMITTED ON GRADESCOPE. There is NO MAKEUP for missed assignments;
in place of that, we drop the three lowest scores (if you have zeros, those are the three lowest scores.)

This homework concerns the parser which was livecoded in class, which is available online here: https://github.com/UCSB-CS56-M16/cs56-livecoded-parser. Some of these questions may require Google.

(10 pts) Please fill in the information at the top of this homework sheet, including your name and umail address. Put the time your discussion section starts (either 9am or 10:30am) in the space indicated. If the other two items apply, please fill them in as well. Please do this every single time you submit homework for this class.
(10 pts) Why can't the this reserved word be used in a static method?
(10 pts) Assume we are just starting to write the parser for an arithmetic expression language very similar to the one in the livecoded parser. Of the following three tests, circle the one which would be best to start off with (worth 2 points), along with your reasoning (worth 8 points). Your reasoning should include information about what it means if the test fails.
- "1"
- "12+327"
- "14-2+98"
(10 pts) In general, if all tests for a given program pass, this does not guarantee that the program is correct. Name one reason why the program might still be incorrect.
(10 pts) When is it appropriate to mark a variable with the final reserved word?
(20 pts) Consider the code in the box below. As shown, this code will catch FooException without doing anything with it. Catching an exception and failing to do anything with it is generally considered bad practice, as this often means that a particular kind of error is silently ignored (specifically, a FooException in the provided code snippet).
```
public static void foo()
  throws FooException {
  ... // implementation not shown
}
public static void main(String[] args) {
  try {
    foo()
  } catch (FooException e) {
    // do nothing
  }
}
```
However, in the livecoded parser, there are multiple places where instances of ParseException are similarly caught without any corresponding code in the catch block. Why is this considered correct behavior for the parser? Your answer should include what it means to throw a ParseException.
(15 pts) In the parse() method of the livecoded parser, there is a check which will throw a ParseException if any tokens remain. Proivde an input which would incorrectly parse if this check were removed.

(15 pts) The code in the box below does not compile. Explain why not.

// In Foo.java
public class Foo {
  private int x = 0;
}
// In Bar.java
public class Bar {
  public static void baz() {
    Foo f = new Foo();
    f.x = 7;
  }
}