Developing a class to ease student coding crash proof and valid IO - Page 2

[AssertNull]

PM sent.

did you agree with my suggestion of adding everything to a List and having a method to save its contents?

Yes. See new code. input is an ArrayList of Strings. writeInputToFile(String) does that. When testing it, I had a quick call to ask if they wanted to save and if so, to what filename. Something like this at the bottom of main.

if(ui.isYes("Do you want to save the input to a filename?))
    ui.writeInputToFile(ui.getString("Enter filename: ").trim());

In the process, I thought that it would be good to be able to to turn on and off logging so that "yes" and the filename was not included, so I added the quick option to turn it off and on. And the option to clear it. Both are one-liners. The JavaDoc comments are longer than the code. The "try" section of getString is now this (logging variable is a boolean).

        answer = br.readLine();
        if(logging)
            input.add(answer); // logging input

See below for new functions. Constructors remain the same (ie your original ones, the one taking a boolean and dealing with logging and/or output has been removed and instead used as a method, not a constructor). Change or remove as needed.

/**
 * Setter for logging variable
 * <BR> (Intended for running repeatable test cases)
 *
 * @param on if true, start/continue logging. if false, stop / do not log.
 */
public void setlogging(boolean on)
{
    logging = on;
}

/**
 * Clears the input log.
 * <BR> (Intended for running repeatable test cases)
 *
 */
public void clearLogging()
{
    input = new ArrayList<>();
}

/**
 * Writes all input to a file for later use test cases.
 * <BR> (Intended for running repeatable test cases)
 *
 * @param filename a file to write to
 * @throws RuntimeException an unrecoverable error occurred
 */
public void writeInputToFile(String filename)
{
    File file = new File(filename);
    System.out.println("Writing input to file " + file.getAbsolutePath());
    try {
        PrintStream outputFile = new PrintStream(file);
        for(int i = 0; i < input.size(); i++) {
            outputFile.println(input.get(i));
        }
        outputFile.close();
    } catch (FileNotFoundException ex) {
        ex.printStackTrace();
        throw new RuntimeException(ex);
    }
}

[JamesCherrill]

Excellent!
Thinking more about the use case, I wonder if it would be more useful to use a standard file save dialog for saving the input? Maybe a no-args overload of writeInputToFile?

Thanks for the pm. I'll deal with that when I get home next week.
J

[JamesCherrill]

More thoughts...
I think the default for logging input should be true, so all you need to do is write the data at the end. The setter would only be needed if you wanted to turn logging off, although I still can't see a use case for that.

As for writing the file, maybe we should set a good Java 8 example by using Files.write(path, userInput); Or at the very least use an enhanced for loop.

[AssertNull]

Regarding the File Save Dialog, I wrote one and when running it, especially in NetBeans as opposed to actual console command line, it ended up BEHIND the window so I had to minimize things to see it. If we add stuff like "focus" code, we're no longer in newbie territory. I'll note the same thing regarding iterating through the ArrayList with a for-loop. NetBeans has some nice hints that pop up on code like I wrote, and what popped up were the ideas you mentioned. However, not everyone is using or teaching Java 8 (whether they SHOULD is a separate issue). Regarding the enhanced for-loop, it seems (to me) at least a little less "newbie" than the regular old for-loop with an i index. Could just be because I already knew C++ before encountering Java and the syntax was familiar.

Standard disclaimer applies regarding "No problem if you want to change it", as it does below. I'm just noting my thinking here.

Regarding logging, just my personal preference when creating test cases to be able to be able to turn it on and off as needed and only log the "meat" of the input (in this case the while loop and NOT the "Do you want to save?" and filename questions). Your File Save Dialog example is a good one. Suppose you and I want to exchange test data? You use a File Save Dialog, so the filename wouldn't end up in the saved file. I do it by asking the user a few questions, which WILL end up in the saved file. Or suppose we did it like I did it originally, where a bunch of questions are asked about files BEFORE gettting to the main loop and created some test files. We now have to edit those old files and take all those leading yes/no and filename question answers out if we want to run those test files on the new version. Otherwise potentially we have names like "yes", "no", and "output.txt" instead of "Fred", "Sue", and "Bob". The option to turn off, turn on, and clear logging, gives you more control, potentially reduces errors and confusion, and saves you time IMO.

[JamesCherrill]

Interesting discussion,
You convinced me that there are real use cases for turning logging on and off, so my only beef there is that I think it should be on by default so the simplest cases really are simple.
Don't know why you had that focus issue with file save dialog. I've never seen that myself, and i know that you are not supposed to need anything yourself to manage the focus.
It's funny how old-time coders can't see how clunky and convoluted the traditional for loop is, especially if you just want to loop through all the members of some collection. For a beginner I would start with the simple "enhanced" for loop, and only get into the three-arg for construct later.
Java 8 has been the current version for more that 2 years now. When are we going to start promoting the many superior features of 8 if not now?

(All the above is, of course, just my personal opinion!)

[AssertNull]

Regarding the File Save Dialog, I'd never done it outside of a GUI and it's quite possible I did it wrong or made it more complicated than necessary. I didn't spend a whole heck of a lot of time on it and I threw away that code, so I'm not 100% sure what I did, but when I did it in a GUI, I had always specified a parent Component and a nice modal Dialog would pop up on top. Here I specified null for the parent. That might have something to do with it. Again, the problem seemed to be when I ran it in NetBeans. It NEVER popped up in front there without doing some tinkering with focus. From an actual command line, it usually popped up in front, but if my memory is correct, there was a time or two that it didn't, but not positive. If you want to implement it, go for it. I'd be interested in seeing the code and trying it in NetBeans.

I think anyone who was going to weigh would have done so by now and it's at the "More than one cook spoils the broth" point. We've both registered our opinions and thrown in the "that's my opinion" qualifier. I think that since you're the mod, you're the cook on this one. Change as you see fit and pin it.

[JamesCherrill]

Right, it's done.
Final code and JavaDoc can be found at https://www.daniweb.com/programming/code/506346/a-simpler-safer-alternative-to-java-util-scanner