Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Java

Posted by Paul Elliott
Paul Elliott
2,882 Points

BufferedReader.readline() can return null on EOF.

According to some documentation I have read, BufferedReader.readline() can return null on EOF. Should not the setting of choice to "" be moved inside the loop?

5 Answers

Paul Elliott
Paul Elliott
2,882 Points
Paul Elliott
Paul Elliott
2,882 Points

Yes, it is a bug. bufferedReader.readLine can return null, if a Unix/Linux user types ^D. Maybe also in Windows on ^Z. I have not checked this on windows as I do not have a windows machine. It does not throw an exception because a file closing EOF is a normal event.

The meaning is "I am closing the file and am not going to interact anymore." It is an expression of human sovereignty. Programs need to check for this. If they don't they will crash when they attempt to use a null pointer as data.

My original solution was wrong. This response needs to be interpreted as "quit".

Alexander Nikiforov
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,175 Points

Hi, Paul :)

Nice suggestion only now I indeed see your problem. It does indeed gives null when typing 'Ctrl-D'.

But there is no way I could've guessed it from your question.

Indeed in promptAction method Craig should check for null on the line 35 promptAction, video at 08:57

https://teamtreehouse.com/library/java-data-structures/efficiency/design-the-ui

if (choice != null) {
  return choice.trim().toLowerCase();
} else {
  return ""; // return empty for example, just for code with equals to proceed
}

In this case when he will use promptAction in run, we won't have NullPointerException and our code should go to default case:

choice = promptAction();
switch(choice) {
  default: 
   // here will go our code, if you type Ctrl+D
}

And while will be OK, because we returned empty String

do {
 // ommited for brewity
} while(choice.equals("quit")); // will be OK, no NullPointerException

Indeed very nice suggestion, I will ask him in Slack, what he thinks about that.

Alexander Nikiforov
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,175 Points
Alexander Nikiforov
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,175 Points

Provide at least link to video, where you are?

Or better paste code, that confuses you.

You have to take care of null when you read from file yes.

When you use readLine prompting for user input, such error will not be thrown...

So, what is

Should not the setting of choice to "" be moved inside the loop?

I've no idea ... Please specify

Paul Elliott
Paul Elliott
2,882 Points
Paul Elliott
Paul Elliott
2,882 Points

I am on Java Data Structures, doing the lesson where they begin to build the Karaoke machine.

Paul Elliott
Paul Elliott
2,882 Points
Paul Elliott
Paul Elliott
2,882 Points

I am on Java Data Structures, doing the lesson where they begin to build the Karaoke machine.

Paul Elliott
Paul Elliott
2,882 Points
Paul Elliott
Paul Elliott
2,882 Points

If you return the empty string on ^D =EOF, you confound the cases where the user typed a simple return with the case when the user typed ^D. This leaves the higher levels of the program no way to know the difference. The level of the switch statement may be willing to try again if the user typed an empty line. However once the user types ^d the file is closed, and all attempts to read the file will result in null, so there is no way to retry with expectation of a different answer. The meaning of EOF is "I am not talking to you anymore". Once the OS notes this it does not even check if the user types something, it just returns an EOF indication without even checking. If an infinite loop is to be avoided, the switch statement must do one of two things 1) call exit itself. 2) change the answer to "quit" to drop out of the for loop. I suggest 2) because the meaning of EOF is a stronger version of "quit". It is more elegant. But for the switch statement to do the right thing, (whatever it is,) it must know what happened.

According to <a href="http://stackoverflow.com/questions/10332132/how-to-use-null-in-switch">this stack overflow page</a> a switch statement always chokes on null. If null is to be returned, you must use a weird combination of an if and a switch statement.

So either the switch statement should be changed to a hybrid if/switch statement as suggested by stackoverflow or the lower level code promptAction should return some unique string meaning EOF. I susggest "eof". Then a new case could be added which "does the right thing".

But pedagogicly, it is a problem. Craig probably does not want to deal with these nuances at this point in his presentation.