This week's book giveaways are in the Angular and TypeScript and Web Services forums.
We're giving away four copies each of Programming with Types and The Design of Web APIs and have the authors on-line!
See this thread and this one for details.
Win a copy of Programming with Types this week in the Angular and TypeScript forum
or The Design of Web APIs in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Henry Wong
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Joe Ess
  • salvin francis

Logic help for my program

 
Sheriff
Posts: 14614
243
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:This current method cannot handle input validation, so it either needs a guarantee that input will be in the correct format or to throw an exception.


Why do you say it can’t handle user input validation? Of course it can. The programmer just hasn’t written any code that does.

There’s no guarantee that any user will do what your program instructions tell them to do. Therefore, it’s the programmer’s responsibility to gently reject any user input that can’t be used either by ignoring the bad value or displaying some kind of helpful message. An exception stack trace is not the kind of message that is helpful to the user.
 
Junilu Lacar
Sheriff
Posts: 14614
243
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which of the following experiences would you prefer as a user of this program:

Experience A

Experience B


 
Marshal
Posts: 66980
255
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . There’s no guarantee that any user will do what your program instructions tell them to do. . . . .

I think it is only a matter of time before a user mistakenly enters something wrong.
Shouldn't the validation be done elsewhere?
In which case my case collapses, iff all input methods can be relied on to do input validation. As long as you can rely on such validation, you can be sure the up‑down method won't throw that exception. But what if somebody else find that up‑down method is public and sends invalid input to it?
I agree that the user doesn't want an incomprehensible stack trace. That wouldn't however be the user's fault, but the fault of whoever failed to validate input. Agree if you have input validation, as I showed with a loop earlier, and can rely on never throwing that exception, the goodbye “throw”, but what if somebody calls it without validating input? Surely it is the input method's responsibilty to validate it? And the only way it can know about that is by having an exception thrown at it.
 
Junilu Lacar
Sheriff
Posts: 14614
243
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Surely it is the input method's responsibilty to validate it? And the only way it can know about that is by having an exception thrown at it.



When you're writing a program that you want to sensibly handle input validation, there are a few "stances" or points of view you should take into consideration:

1. User's stance -- I can enter whatever I please, your program needs to be robust enough to gracefully handle my dumb mistakes

2. Programmer's stance -- I need to validate user's input and make sure I'm not making any internal calls that will blow up.

3. A class with an API -- I am going to specify what valid input you (the programmer) are expected to give me so I can do my job. You need to take care of validation. If you don't give me the kind of data I expect, I'm going to throw a RuntimeException in your face to remind you of your responsibilities as a programmer.

The example you gave with the Color constructor is the third stance.

What we've been talking about with OP's program are the user's and programmer's stances.
 
Ranch Foreman
Posts: 240
5
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think the input scheme should be closer to what a real-life elevator provides, you have discrete buttons, input is strict and well defined, you either pressed a button or you didn't.

so i suggest an array of button objects, one per floor. you can have a list of valid floor names in an enum and if the user doesn't type one of those names exactly as input, then you just ignore the input. otherwise you can register a button.press() for that floor.

the maximum amount of requests for the elevator can be limited to how many buttons are available to be pressed. imagine a prankster who would be able to make an endless queue of elevator requests so that the elevator will keep moving all day long. you ignore additional requests if the button is already pressed.
 
Marshal
Posts: 7347
498
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

S Fox wrote:so i suggest an array of button objects, one per floor.


That doesn't sound as a good idea to me. I'd expect that button 4 could figure out, and act appropriately depending on at which floor it has been pressed. Whether it be floor 2 or 4. So probably in a case of current floor being 4, pressing button 4 should do nothing, while being at level 2 and pressing button 4 it supposed to go two levels up. In different words, if there are 10 levels, I'd expect system to have 10 buttons, and not 100 as you suggest.
 
Campbell Ritchie
Marshal
Posts: 66980
255
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I acknowledge my mistake.
 
Bartender
Posts: 3674
151
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This topic has gone out of hand. It was just an exercise in java, about an elevator that could handle commands like 'U3' and 'D2'. Got little to do with reality. It is therefore completely up to the programmer what to do with it. Throw an exception when a typo is made? Or handle it with grace like Junilu proposed? Up to the programmer, who is wrtiting this code to gain experience and knowledge and is its only user.

This is a nice exercise to practise GUI, though. There you can have all Labels with the floors mentioned, with a big Label showing the current floor, and with a Timer to update that Label when the elevator is on its way.
 
S Fox
Ranch Foreman
Posts: 240
5
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i never suggested to have 100 buttons lol
 
Liutauras Vilda
Marshal
Posts: 7347
498
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

S Fox wrote:i never suggested to have 100 buttons lol

Ok, sorry for misunderstanding you.

Purely out of interest, what did you mean by saying:

so i suggest an array of button objects, one per floor.


?
 
S Fox
Ranch Foreman
Posts: 240
5
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
one array per elevator, containing the buttons you would normally find in an elevator. so just a single button for each floor.
i think you mistook it as one array per floor
 
Junilu Lacar
Sheriff
Posts: 14614
243
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Piet Souris wrote:This topic has gone out of hand. It was just an exercise in java, about an elevator that could handle commands like 'U3' and 'D2'. Got little to do with reality. It is therefore completely up to the programmer what to do with it. Throw an exception when a typo is made? Or handle it with grace like Junilu proposed? Up to the programmer, who is wrtiting this code to gain experience and knowledge and is its only user.


1. Agree that this is really just an exercise with specific learning goals, one of which is probably NOT to make it something that is realistic. In that sense, you're right, it's really up to the programmer whether or not they want to add on those "refinements."

2. As far as learning is concerned, various tips were put on the table that were probably outside the scope of the original learning objectives but were nevertheless relevant to future learning efforts. I think we do all need to learn to strike a balance between helping the OP learn and trying to nitpick at finer points that, while they may be relevant as OP gains more experience, might only serve as distractions that are over OP's head at the moment.

3. Bottom line: let's learn to curb our enthusiasm and focus on the learning objectives of the exercises OPs ask for help on rather than going into a whole seminar on good programming practices. I'll be the first to raise my hand and admit: GUILTY as charged.
 
Piet Souris
Bartender
Posts: 3674
151
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well said, Junilu.

I do not have a problem with a topic extending a little (or far) from the original question, but what I often see in these cases is that poor old OP gets completely out of sight, intimidated probably. Yes, it IS a sign that we are very very willing to help, but that may be a meagre comfort...

Me too, mentioning a nice GUI with beautful Buttons and Labels... mea culpa too
 
Bartender
Posts: 1735
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also saw this interesting posting here on the ranch:  https://coderanch.com/t/671008/java/Elevator-Simulator

A more general discussion of "The Elevator Problem" can be found here: https://web.eecs.umich.edu/~baveja/RLMasses/node2.html

-- mike
 
He loves you so much! And I'm baking the cake! I'm going to put this tiny ad in the cake:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!