Heck yeh! Great work.
I think most critique has been covered.
I consider too-many-indentations to be a code smell.
Not actually an issue, but maybe there is…
There is nothing wrong with your code, and no reason to change it (beyond error catching as you have discovered). It runs, is easy to follow, and doesn’t over-complicate.
I like descriptive function names and early returns (ie, throw or return on all the conditions that means this function shouldn’t continue, then process the parameters to return a result).
This could massively clean up what’s going on.
There could be a “getUserCommand()” that returns the desired number, or 0 if it’s invalid.
If the returned value is 0, then break.
If the returned value is 6, then print values; then break.
Otherwise we know the value should be 1-5.
You could use an Enum to define the choices.
This way, the print lines and the conditional tests can both reference the enum. It also removes “magic numbers” (IE values that appear in code with no explanation).
In something simple like this, it doesn’t really matter. But it improves IDE awareness (helping language servers suggest code/errors/fixes). And Makes the code SOO much more descriptive (Ie “choice == 3” becomes “choice == Choices.Product”).
I clean my windshield if someone is too close behind.
The wind always carries some spray over the top and hits their car and they have to wipe their windshield.
It might seem petty, but seems to trigger something subconscious that makes them back off a bit.
It always seems to work