给出(一个)带有'catch(Exception)'子句的不良事件的例子

这是对此问题的后续问题.

人们普遍认为,做一个广泛的'捕获(例外)'是一个坏主意.

推理通常类似于"你必须正确处理异常"和"抓住你能处理的东西"和其他一些通用的声音参数.

那些通用的答案听起来很合理,但它们并不能让我满意.

让我具体一点.这是典型的代码,它应该是"坏的".

try {
   ... do something...
} catch (Exception e) {
   log(e); //leave a trace for debugging
   return ...a value the context can deal with...
}

一个怀疑的头脑仍然不相信不处理异常(这可能会炸毁整个程序),必然比以这种通用方式处理它更好.

所以我真的想要一些特定的,令人信服的例子,带有代码片段,实际上发生了一些不好的事情,因为一个像上面那样过于宽泛的catch子句.

PS:人们可以用Java以外的其他语言来思考这个问题,但是由于我想要特定的例子,这实际上是关于Java程序和JRE可能引发的特定异常.

PS2:我特别感兴趣的是Exception的例子,它实际上是java.lang.Exception的子类型,而不是更广泛的'Throwable'.因此,排除像'OutOfMemoryError'这样的东西作为有效的例子.

捕获NullPointerException可能导致应用程序无意中忘记了它所需要的东西没有完成的事实.稍后应用程序将再次失败或行为异常,因为之前的操作没有完成,但现在更难以弄清楚.

在事务中吃异常可能导致事务本来没有回滚.您最终可能会得到不一致的数据.

吃顿干的异常:

public void run() {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            doSomeWork();
            Thread.sleep();
        } catch (Exception e) {
        }
    }
}

如果线程在休眠时被中断,则当sleep方法抛出InterruptedException时,中断的标志将被重置,因为catch不会恢复中断标志,while循环条件保持为false并且线程不会退出.

同样,由于InterruptedIOException是IOException的子类:如果您的网络IO代码只处理IOException,那么您可能无法恢复中断标志并且无法检测到您的线程已被中断.