此外,可以假设程序无法从RuntimeExceptions中恢复.
现在,我经历了一种情况,由于用户输入无效,我可能会收到IndexOutOfBoundsException：程序从 HTML表单接收一个String,如果它包含一个整数,则要验证它.
基本上,指定的String与模式匹配,然后确定逗号的位置.之后,有必要检查逗号后面的第一个数字,以决定如何正确地舍入它.这是关键部分：
firstDecimalChar = formattedValue.charAt(dotPosition + 1);
如果用户输入类似“27”的内容,则此语句将抛出异常.由于这是基于奇怪的用户输入,我想知道这个异常是否真的像一个常见的异常(可以这么说).
我认为这是因为在大多数教程(例如oracle)中,他们将检查的异常分类为由无效输入导致的错误,即错误的路径名称到应该打开的文件,并且通过一些更正或用户提示可以恢复从那个错误.同样在这里：人们可能只是将上面的变量设置为零,因为当有人插入“27”时这意味着什么. – > “27.0”
这个捕获并指定要求真的那么严格吗？当然,如果位置不在界限之内,可以事先简单地检查,但我的问题是,如果在已检查和未检查的异常之间确实存在这样的直线.我想知道为什么要尽可能经常避免异常有任何技术上的缺点. (有人提到JVM开销,但是它有意义吗？)
我想我需要在这里进行更深入的澄清,因为大多数教程并没有让我相信：“你根本就不应该这样做”.因为我认为在这种情况下,此异常的行为类似于一个易于恢复的已检查异常.
注意：在我的代码中,我先检查字符串位置是否有效,并且没有捕获异常 – 所以这不是这个问题的一部分：)但是这种情况让我很忙.
解决方法
Is that catch and specify requirement really that strict?
不,我认为在某些情况下可以捕获未经检查的异常(RuntimeExceptions).
例如,如果用户输入一个数字,我认为这样做完全没问题
double i;
try {
i = Double.parseDouble(userInput);
} catch (NumberFormatException e) {
addValidationError("Entered number is not valid: " + userInput);
}
如果异常是意外的并且对应于代码中的错误,请不要理会它(或者在最顶层捕获,例如在handleRequest或其他任何情况下,并返回500错误).另一方面,如果您可以预见抛出异常,(并且使用普通控制结构(例如if语句来覆盖这些情况,例如上面的NumberFormatException示例)会捕获并处理它.
碰巧,RuntimeExceptions通常对应于程序员错误,并且说“不捕获RuntimeExceptions”可能被视为捕获和捕获的内容的良好近似值.
当开发人员决定是否扩展Exception或RuntimeException时,他/她会考虑强制客户端声明throws子句/捕获异常是否合理.在某些情况下,异常可能是由于编程错误和“正常操作”错误引起的.在这种情况下,强制抛出/捕获客户端是不礼貌的,并且更适合使其成为RuntimeException.在客户端代码中,异常实际上用于指示“正常操作”错误,它仍然适合捕获它.
相关问题(但主要基于意见关闭)：stackoverflow.com/questions/24344511/why-is-catching-a-runtimeexception-not-considered-a-good-programming-practice
