如何在 Java 中利用 Scanner.nextShort() 严格限制读取符合短整型范围的控制台输入

如何在 Ja va 中利用 Scanner.nextShort() 严格限制读取符合短整型范围的控制台输入

想在Ja va里让用户输入一个合法的short类型数字（-32768到32767），光靠Scanner.nextShort()这个方法可不够。它确实会拒绝字母和越界的数字，但方式比较“粗暴”——直接抛异常就停了，不会给你自动重试的机会，更别提清晰的错误提示了。要想实现真正“严格”的控制，你得把异常处理、缓冲区清理和范围校验这几样功夫都做到位，形成一个完整的逻辑闭环。

捕获 InputMismatchException 并清空非法输入缓冲区

当用户输入的不是数字，比如敲了个“abc”或者带小数点的“12.5”，nextShort()会立刻抛出InputMismatchException。问题在于，这个非法输入会一直卡在Scanner的缓冲区里。如果你不处理，下次循环再调用nextShort()，它还会试图读取同一个错误数据，程序就陷入死循环了。

所以，正确的做法是：

• 用try-catch块把nextShort()的调用包起来，专门捕获InputMismatchException。
• 在catch块里，关键一步是调用一次scanner.next()。这个操作就像清道夫，能把缓冲区里那个捣乱的非法输入“吃掉”，让Scanner的读取指针移动到下一个位置。
• 清理完之后，别忘了给用户一个友好的提示，告诉他输入有误，然后继续循环等待下一次输入。

手动校验数值是否真正落在 short 范围内

你可能以为nextShort()能搞定所有范围问题，其实不然。对于明显超出范围的超大整数（比如100000），它确实也会抛出InputMismatchException（因为内部解析失败了）。但在一些更精细的场景下，比如你想区分“格式错误”和“数值越界”并给出不同提示，或者想先读取再判断，就需要更主动的策略。

一个更稳妥、可控性更强的方案是：先别急着用nextShort()，而是改用nextLong()把输入作为长整型读进来。拿到这个长整型数值后，你再手动检查它是否同时满足“≤ 32767”和“≥ -32768”这两个条件。只有完全符合，你才放心地把它强制转换成short类型。

• 这样做的好处是，避免了nextShort()遇到大数时直接“崩溃”，把控制权掌握在自己手里。
• 举个例子，用户输入“32768”，nextLong()能成功读到32768，然后你一检查，发现它大于32767，于是可以明确地拒绝并提示“数值超出short范围”。
• 这样一来，“输入了字母”和“输入了过大的数字”就成了两种可以区别处理的错误，用户体验会好很多。

封装成可复用的安全输入方法

把上面这一套组合逻辑写成一个独立的工具方法，绝对是明智之举。代码清晰了，也能避免在项目里到处复制粘贴。

方法签名可以设计成public static short readShort(Scanner sc, String prompt)。方法内部是一个循环：先打印传入的提示语，然后尝试读取。如果读取过程中间出现任何异常，或者数值校验不通过，就清理缓冲区、打印错误信息，然后继续循环，直到用户输入一个完全合法的值为止。

在实现时，更推荐采用“nextLong() + 范围判断”的方案来替代直接使用nextShort()，这样在健壮性和控制精度上都能兼顾。你还可以考虑为这个方法增加一个“最大重试次数”的参数，防止用户无限次地输入错误，让程序更有弹性。

说到底，Scanner.nextShort()自带的“严格”仅仅停留在语法类型匹配的层面。要想达到业务级别的严格限制——即确保输入绝对合规且体验流畅——开发者必须自己动手，补上缓冲区清理和范围二次验证这两个关键环节，把逻辑的闭环画圆。这才是关键所在。