线程池会吞掉异常你相信吗？

KeepSayingNo 2016-12-03 09:38:03

写了一篇文章分析了线程池吞掉异常，希望开发者在使用的时候多个心眼，顶贴和顶Blog的给高分啊。

...全文

510 10 打赏收藏转发到动态举报

写回复

用AI写文章

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

Ty_Herry 2016-12-05

打赏
举报

我是新手，来学习下，顶一下

KeepSayingNo 2016-12-05

打赏
举报

引用 8 楼 aqzwss 的回复:

[quote=引用 7 楼 dotnetstudio 的回复:] [quote=引用 6 楼 aqzwss 的回复:] 看了一下，个人感觉题目可能会有点主观因素在里面，可能会对某些人产生误导。以下为个人观点，仅供参考：首先我们在使用java类的时候就需要弄明白该类被设计出来的目的是什么，需要如何使用，会有什么表现，异常是抛出、内部处理还是忽略等等，只有在了解这些之后才能正确的使用这个类进行编码开发，否则就是满意的写出充满BUG的代码而不自知。对于ExecutorService中submit()与execute()方法对于异常的处理有人已经总结出来了： There is a difference concerning exception/error handling. A task queued with execute() that generates some Throwable will cause the UncaughtExceptionHandler for the Thread running the task to be invoked. The default UncaughtExceptionHandler, which typically prints the Throwable stack trace to System.err, will be invoked if no custom handler has been installed. On the other hand, a Throwable generated by a task queued with submit() will bind the Throwable to the Future that was produced from the call to submit(). Calling get() on that Future will throw an ExecutionException with the original Throwable as its cause (accessible by calling getCause() on the ExecutionException). 也就是说execute()就是被设计为“吞掉”异常的，我们在使用之前就应该清楚这一点，而不是在模糊不清认为存在异常会抛出的情况下一直使用该类，却在某个时间点突然发现与原来不符而感性的认为execute()方法居然是不可思议的“吞掉”了本该抛出的异常。这在语言运用的本质上就是本末倒置了。

你这个分析得很好，请问你这段英文是从哪里得到的[/quote] stackoverflow 程序员建议还是用google搜索，百度你懂的。[/quote] stackoverflow 很不错的网站

KeepSayingNo 2016-12-04

打赏
举报

引用 6 楼 aqzwss 的回复:

看了一下，个人感觉题目可能会有点主观因素在里面，可能会对某些人产生误导。以下为个人观点，仅供参考：首先我们在使用java类的时候就需要弄明白该类被设计出来的目的是什么，需要如何使用，会有什么表现，异常是抛出、内部处理还是忽略等等，只有在了解这些之后才能正确的使用这个类进行编码开发，否则就是满意的写出充满BUG的代码而不自知。对于ExecutorService中submit()与execute()方法对于异常的处理有人已经总结出来了： There is a difference concerning exception/error handling. A task queued with execute() that generates some Throwable will cause the UncaughtExceptionHandler for the Thread running the task to be invoked. The default UncaughtExceptionHandler, which typically prints the Throwable stack trace to System.err, will be invoked if no custom handler has been installed. On the other hand, a Throwable generated by a task queued with submit() will bind the Throwable to the Future that was produced from the call to submit(). Calling get() on that Future will throw an ExecutionException with the original Throwable as its cause (accessible by calling getCause() on the ExecutionException). 也就是说execute()就是被设计为“吞掉”异常的，我们在使用之前就应该清楚这一点，而不是在模糊不清认为存在异常会抛出的情况下一直使用该类，却在某个时间点突然发现与原来不符而感性的认为execute()方法居然是不可思议的“吞掉”了本该抛出的异常。这在语言运用的本质上就是本末倒置了。

你这个分析得很好，请问你这段英文是从哪里得到的

萧乡月夜 2016-12-04

打赏
举报

引用 7 楼 dotnetstudio 的回复:

[quote=引用 6 楼 aqzwss 的回复:] 看了一下，个人感觉题目可能会有点主观因素在里面，可能会对某些人产生误导。以下为个人观点，仅供参考：首先我们在使用java类的时候就需要弄明白该类被设计出来的目的是什么，需要如何使用，会有什么表现，异常是抛出、内部处理还是忽略等等，只有在了解这些之后才能正确的使用这个类进行编码开发，否则就是满意的写出充满BUG的代码而不自知。对于ExecutorService中submit()与execute()方法对于异常的处理有人已经总结出来了： There is a difference concerning exception/error handling. A task queued with execute() that generates some Throwable will cause the UncaughtExceptionHandler for the Thread running the task to be invoked. The default UncaughtExceptionHandler, which typically prints the Throwable stack trace to System.err, will be invoked if no custom handler has been installed. On the other hand, a Throwable generated by a task queued with submit() will bind the Throwable to the Future that was produced from the call to submit(). Calling get() on that Future will throw an ExecutionException with the original Throwable as its cause (accessible by calling getCause() on the ExecutionException). 也就是说execute()就是被设计为“吞掉”异常的，我们在使用之前就应该清楚这一点，而不是在模糊不清认为存在异常会抛出的情况下一直使用该类，却在某个时间点突然发现与原来不符而感性的认为execute()方法居然是不可思议的“吞掉”了本该抛出的异常。这在语言运用的本质上就是本末倒置了。

你这个分析得很好，请问你这段英文是从哪里得到的[/quote] stackoverflow 程序员建议还是用google搜索，百度你懂的。

萧乡月夜 2016-12-03

打赏
举报

看了一下，个人感觉题目可能会有点主观因素在里面，可能会对某些人产生误导。以下为个人观点，仅供参考：首先我们在使用java类的时候就需要弄明白该类被设计出来的目的是什么，需要如何使用，会有什么表现，异常是抛出、内部处理还是忽略等等，只有在了解这些之后才能正确的使用这个类进行编码开发，否则就是满意的写出充满BUG的代码而不自知。对于ExecutorService中submit()与execute()方法对于异常的处理有人已经总结出来了： There is a difference concerning exception/error handling. A task queued with execute() that generates some Throwable will cause the UncaughtExceptionHandler for the Thread running the task to be invoked. The default UncaughtExceptionHandler, which typically prints the Throwable stack trace to System.err, will be invoked if no custom handler has been installed. On the other hand, a Throwable generated by a task queued with submit() will bind the Throwable to the Future that was produced from the call to submit(). Calling get() on that Future will throw an ExecutionException with the original Throwable as its cause (accessible by calling getCause() on the ExecutionException). 也就是说execute()就是被设计为“吞掉”异常的，我们在使用之前就应该清楚这一点，而不是在模糊不清认为存在异常会抛出的情况下一直使用该类，却在某个时间点突然发现与原来不符而感性的认为execute()方法居然是不可思议的“吞掉”了本该抛出的异常。这在语言运用的本质上就是本末倒置了。

萧乡月夜 2016-12-03