为什么Java人经常默默地使用异常？

Question

我之前从未做过任何严肃的Java编码,但我根据现有技能(Delphi和C#)学习了语法,库和概念.我很难理解的一件事是,我已经看到了这么多代码,在printStackTrace这样的情况下默默地消耗异常:

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            e.printStackTrace();
        }
    }

在我遇到的几乎所有Java文章和项目中都有类似的代码.根据我的知识,这是非常糟糕的.几乎总是应该将异常转发到外部上下文,如下所示:

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            e.printStackTrace();
            throw new AssertionError(e);
        }
    }

大多数情况下,异常最终应该在属于底层框架的最外层循环中处理(例如Java Swing).为什么Java世界中的代码看起来像这样的规范？我很困惑.

根据我的背景,我宁愿完全删除printStackTrace .我会简单地重新抛出一个未处理的aka RuntimeException(或更好的AssertionError),然后捕获并在最合适的位置记录它:框架最外层循环.

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            throw new AssertionError(e);
        }
    }

Answer 1

我一直认为,这与以下场景类似:

"一个人被枪杀了.

他屏住呼吸,有足够的力量乘坐公共汽车.

10英里后,这名男子下车,走了几个街区,然后死了."

当警察到达尸体时,他们不知道刚刚发生的事情.他们最终可能会有,但更难.

更好的是:

"一名男子被枪杀,他立即死亡,身体正好位于谋杀刚刚发生的地方."

当警察到达时,所有证据都已到位.

如果系统失败,最好是快速失败

解决问题:

1. 无知.
   +
2. 懒惰

编辑:

当然,捕获部分很有用.

如果可以通过异常完成某些事情,那就应该在那里完成.

可能这不是给定代码的例外,可能它是预期的东西(在我的比喻中就像一个防弹夹克,而男人正在等待拍摄的第一个位置).

是的,捕获可用于抛出适合抽象的异常

Answer 2

通常这是由于IDE提供了一个有用的"快速修复",它将使用该异常处理的try-catch块中的违规代码包装起来.这个想法是你实际上做了什么,但懒惰的开发人员没有.

毫无疑问,这是糟糕的形式.

Answer 3

1. Java强制您明确处理所有异常.如果您的代码调用的方法被声明为抛出FooException和BarException,则您的代码必须处理(或抛出)这些异常.唯一的例外是RuntimeException,它像忍者一样沉默.
2. 很多程序员都很懒(包括我自己),只需打印堆栈跟踪就很容易了.

Answer 4

这是一个经典的稻草人论点. printStackTrace()是一个调试辅助工具.如果你看到它在博客或在一本杂志,这是因为笔者更感兴趣的是说明一点其他比异常处理.如果你在生产代码中看到它,那段代码的开发者就是无知或懒惰,仅此而已.它不应该被视为"java世界"中常见做法的一个例子.

Answer 5

我发现这有两个原因

1. 程序员很懒
2. 程序员想要保护进入该组件的入口点(正确或错误)

我不相信这是一种仅限于Java的现象.我也经常在C#和VB.Net中看到这样的编码.

从表面上看,它非常震撼,看起来很糟糕.但实际上并不是什么新鲜事.它始终出现在使用错误代码返回值与异常的C++应用程序中.但不同之处在于,忽略可能致命的返回值与调用返回void的函数看起来并没有什么不同.

Foo* pFoo = ...;
pFoo->SomeMethod(); // Void or swallowing errors, who knows?

这段代码看起来更好但是如果SomeMethod()要说返回一个HResult,那么它在语义上与吞下异常没什么不同.

Answer 6

因为Checked Exceptions是一个失败的实验

(也许printStackTrace()是真正的问题？:)

Answer 7

我不得不说我略微反感暗示这种松散的错误处理行为是Java程序员的基础.当然,Java程序员可能很懒,就像其他程序员一样,而Java是一种流行的语言,所以你可能会看到许多代码吞噬了异常.

此外,正如其他地方所指出的那样,Java强制声明已检查的异常是可以理解的,尽管我个人对此没有任何问题.

我想,我遇到的问题是,你在网上轻松浏览一堆文章和代码片段而不必费心去考虑上下文.事实是,当你写一篇技术文章试图解释一些特定的API如何工作,或者如何开始使用某些东西时,那么你很可能会跳过代码的某些方面 - 错误处理不直接与您所展示的内容相关的可能是处置的候选者,尤其是在示例场景中不太可能发生异常的情况下.

写这种性质的文章的人必须保持合理的信噪比,而且相当公平,我认为,这意味着他们必须假设你已经掌握了一些关于你正在开发的语言的基础知识; 如何妥善处理错误,以及其他一些事情.如果您遇到一篇文章,并注意到缺少正确的错误检查,那就没关系; 只是确保当你将这些想法(但当然,从来没有确切的代码本身,对吗？)纳入你的生产代码时,你将处理作者明智地遗漏的所有那些碎片和爆炸,以一种最大的方式适合你正在开发的东西.

我确实遇到了一些非常高级的介绍性文章的问题,这些文章在没有返回它们的情况下轻易解决这些问题,但请注意,Java程序员没有一些关于错误处理的特定"思维模式"; 我知道很多心爱的C#程序员,他们也不打算处理他们遇到的所有问题.

Answer 8

System.out打印或e.printStackTrace() - 暗示使用System.out通常是一个红旗,意味着有人没有费心去做勤奋的工作.除了桌面Java应用程序之外,大多数Java应用程序最好使用日志记录.

如果方法的失败模式是无操作,那么无论是否记录原因(和存在),都可以完全没问题.然而,更典型的是,catch子句应采取某种特殊行动.

重新抛出异常是最好的做法,当你使用catch来清理部分工作时,必要的信息仍然可用,或者你需要将异常转换为更适合调用者的异常类型.