Apero offers a valid and valuable learning point in suggesting that the order of the tests be changed.

But (in an exchange via CB) Apero cites the possibility that an idiot responding to a prompt asking for integers between 0 and 91 with "hi" will cause perl to "spew warnings." I disagree with the view that this is a bad thing in this case.

In fact, the issuance of warnings might (well, not likely, but "might") cause my not-entirely-hypothetical idiot to actually read the prompt, once that's written in a manner which makes the required input explicit.

And, while I'm (politely, I trust) disagreeing with fellow Monks, the notion of adding a prompt module from BillKSmith is also, IMO, a valid teaching point, but an unnecessary addition to overhead, because OP's intent (as stated in the narrative) is simply validation of an input. Further, since OP's code - were it corrected as ExReg suggests or as modified in my note - does the same job, inline and very clearly for any future reader or maintainer.

Fixed: missing char and extra close tag

In fact, the issuance of warnings might (well, not likely, but "might") cause my not-entirely-hypothetical idiot to actually read the prompt, once that's written in a manner which makes the required input explicit.

This largely depends on the user audience. Some Perl I write is customer-facing and warnings from the interpreter (be it Perl, Python, or extra debugging printf or println statements in C or Java) are very frowned upon when you're writing code customers will use. Techniques like defensive programming and encapsulating errors really does make a difference when you're writing well-designed, professional code. Granted not all projects require such attention and polishing, so perhaps this was what you were getting at.

I take a fairly strict approach to untrusted input in that it needs to be correctly validated, and I know my audience might not even care to read a line of Perl to use my program. Cluttering the screen of someone who may have simply made a typo with technical jargon (as much as it helps those of us who write Perl) does not increase usability if the error message is well-written, and in fact decreases usability by cluttering the screen with information not all users will be able to understand. If more direct description is required, the error message handling such bad input should be improved.

Point taken.

But, in context, I suspect OP is not quite ready for that level of UI sophistication. In fact, I can't decide whether the question is homework, a test for a prospective Perl apprentice or actual $work from a shop with fairly low hiring standards.

check Ln42!