CS:2820 Exam 1, Fall 2017

Background: Consider the variable command defined as follows:

String command = sc.next(); // sc is a Scanner

a) Is it useful to write: if (command == "gate") (0.5 points) __No_____________

Explanation: sc.next() makes a new string to hold each bit of text that it returns. Therefore command=="gate" will always be false.

Under 1/12 of the class had difficulty here. There was no partial credit.

b) Why not write this: if (command.equals("gate")) (0.5 points) __command = null_

Explanation: There is only a remote possibility that command might be null, but this is enough to discourage use of this form.

Over 1/4 of the class earned no credit. It is hard to classify the problems, but some appear not to have understood that a question starting with "why not ..." requires that the answer be in the form of a reason.

b) Does this ever fail: if ("gate".equals(command)) (0.5 points) __No_____________

Explanation: The expression always evaluates to either true or false, it never throws an exception, even if command is null.

No. About 1/5 earned no credit. Partial credit was granted for a few students who said yes, and then clarified that they interpreted failure as evaluating to false.

Background: In the posted solution to MP2, the constructors for class Gate throws an exception in order to avoid creating a defective object. The call to this constructor looks like this:

try {
    gates.add( new Gate( sc ) );
} catch (Gate.ConstructorFailure e) {
    // do nothing, the constructor already reported the error 
}

A problem: Suppose, instead, that class Gate offered a static factory method (call it factory) that returns null if the source file describes a defective gate. Write code equivalent to the above so it only adds non-defective gates to the list gates. (1.5 points)

__Gate g = Gates.factory( sc );________________________________________

__if (g != null) gates.add( g );_______________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

Over 1/4 got this right.

Among the errors leading to reduced credit: Almost 1/2 forgot to save the result from the factory method so they could test for null. A similar number (with considerable overlap) used a factory and then called new Gate() as well. About 1/5 included a non-empty else to output an error message (despite the comment saying that the constructor we are replacing with the factory takes care of error messages). Another 1/5 added gratuitous code involving exceptions, despite the fact that the problem statement said a return value of null replaced the exception.

Partial credit was not granted to the approximately 1/5 who tried to write the factory method instead of writing code equivalent to the given code but using a factory call instead of a constructor call.

Background: Suppose you wanted to path test the folllowing bits of code. What values of the boolean variables or method calls a and b do you need to test?

a) if(a||b) ... (1 point) __ab = {0,0} {0,1} {1,x} (3 cases)___________

b) if(a&&b) ... (1 point) __ab = {1,1} {1,0} {0,x} (3 cases)___________

About 1/7 got each of these. About 1/8 earned no credit, typically by giving answers that could not be interpreted as values for a and b that might matter in planning a path test. Full credit required an answer that clearly indicated an understanding that the || and && operators are control structures as well as boolean operators, and therefore, that only 3 cases need to be tested because the second operand is not evaluated for some values of the first operand.

Background: Here's some code from class Gate in the posted solution to MP2:

public void registerInput( String pinName ) {
    for (String s: inputs) {
        if (s.equals( pinName )) {
            Errors.warn( "Input reused: " + name + " " + pinName );
	    /***/ return; /***/
        }
    }
    inputs.add( pinName );
}

a) Suppose g.registerInput(s) is called twice. The second time, it gives an error message, but it also has a side effect that might be wrong. What? (0.7 points)

___it does inputs.add(pinName) twice___________________________________

about 1/2 got this, and as may failed.

The most common wrong answer had to do with the possibility that pinName might be null. This is puzzling in the light of the fact that this code is from a posted machine-problem solution, one that works pretty well.

b) Add a statement to the above code to avoid this side effect. (squeeze it in legibly.) (0.8 points)

The code marked with /***/ above was added to solve this problem.

About 1/5 got this. Another 1/8 earned almost full credit for code that was inefficient, for example, using a boolean condition to control the call to inputs.add that defaults to true and is turned off when Errors.warn is called.

Where the wrong answer to part a was clearly stated and where code was given that addressed that issue, full credit was given.

1/3 wrote strange code. Some wrong answers were remarkable, for example, moving the inputs.add call inside the loop so it added pinName over and over, once per iteration.

c) Rewrite the for loop above using an iterator and a while loop (ignore part b). (2 points)

public void registerInput( String pinName ) {

    __Iterator  i = inputs.iterator();_______________________

    while __(i.hasNext()) {__________________________________________

        __String s = i.next();_______________________________________
        if (s.equals( pinName )) {
            Errors.warn( "Input reused: " + name + " " + pinName );
        }
        _____________________________________________________________
    }
    _________________________________________________________________
    inputs.add( pinName );
}

About 1/4 did well and 1/12 left it blank.

1/6 used an integer loop counter, this was penalized since the problem explicitly requested an iterator. About half these used the array notation inputs[i] where Java requires inputs.get(i).

About 1/4 tried to use inputs as an iterator instead of deriving an iterator from it. About 1/6 left s undefined and about 1/12 forgot to advance the iterator. Missing semicolons and missing empty argument lists were not penalized.

In the posted HW5 solution, an executable file test was given that started with:

#!/bin/sh
$1 > actualoutfile 2> actualerrfile

This script was used in another script (in file testscript) by lines like this:

./test "java RoadNetwork" /dev/null test1error "test1 (missing infile)"

a) This line of testscript makes test to compose what shell command? (0.8 points)

__java RoadNetwork > actualoutfile 2> actualerrfile____________________

Only 1/16 got this right. 1/4 dropped the input and output redirection from the command, and a few carried other arguments from the call to ./test into the command line, despite the fact that only one argument was explicitly mentioned, $1.

5/8 earned no credit. Many of these tried to write long explanatory essays that hinged on details from the posted solution to HW5 that were not repeated on the exam and were therefore irrelevant.

b) What does the text > actualoutfile do? (0.7 points)

__Redirect standard output (system.out) to actualoutfile_______________

_______________________________________________________________________

1/4 got this. 5/16 said that something was stored in actualoutfile, for partial credit, but did not indicate what.

3/8 earned no credit here, although many wrote at length about things remembered from the posted solution to MP5 that had nothing to do with this.

Exam 1: Midterm

Solutions and Commentary

Grade Distributions

Exam 1

Machine Problems 1—2

Homework 1—5

Total Scores

Exam Solutions and Commentary