老掉牙的话题，java的异常处理。

比如读取一个默认的配置文件,如果配置文件不存在就生成一个默认的.这种完全是应该调用者处理的,而且他有能力处理的,这种就应该抛出checkedException,
————————————————————
即使你如此的信誓旦旦，这种假设也只是你抛出异常一方的一厢情愿，尤其是你的模块公用性越强那么就越不能自以为是了。也许有些设置就是必须要设置的呢？即使不是，也许不是它直接调用方能处理的呢？

这里有个关键理念不知道你认同不认同：
你的模块就是完成定义的目标，如果完成不了就报告错误，至于错误报告之后的事是不是不应该多管闲事？
如果你认同这个理念，那么checkedException就是错误的设计。

在同等程序员水平的情况下，我刚说的反向测试完善法也比checkedException带来的乱吞状况好很多。而且写程序的时候轻松程度不一样。

异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。

即使一个程序员非常了解异常的意义，也会被checkedException弄得烦死，不得不用RuntimeException包装它，很多开源库就是这么做的。这就是当初这些API设计者在异常上武断的决定导致的，自以为把调用方想透了，其实不过是自以为是而已。

看来你开发的还不够大。请问如果在EDT线程内，你怎么能够快速得知并且受到编译器提示一个方法调用（可能封装了其他的方法）会是一个耗时操作，恰恰checked exception的层层抛出机制可以轻松保证这一点。

不要一棒子打死，异常是否可以反映业务流分支这正应该不用争论了。很多情况下调用者的范围或者调用后程序的行为是可以预知和限定的，程序是死的，人是活的，不要太绝对。

我真是晕了，我使用某个方法都不知道这个方法可能的执行时间？如果我要和server通信那么显然时间可能比较长，这些这么显然的事情需要一个异常来表征？而且不见得IO就是慢的，就一定不能在EDT里面承受，如果我简单读一个配置文件，那么速度很快完全可以放在EDT里面而不需要另外的线程。难道你不觉得通过IOException来判断是这件事很可笑吗？

而且GUI程序，如果我点一下按钮，发现卡了半天，难道你这还不知道慢？而且不问青红皂白看到IOException就要构建后台线程，这本根就是增加复杂性，我们首先当然希望直接在EDT里面就能搞定，只有确实慢了我们才考虑后台线程。

首先，你调用的方法很可能不是你写的，如果你不阅读api doc或看源码的话，很可能“使用某个方法都不知道这个方法可能的执行时间”。另外在程序中层层封装的情况太常见了，特别是大型程序，不利用checked exception层层抛出的机制忽略耗时操作的事情很容易发生。

至于读取本地文件也要看你读多大的，还包括xml解析时间，一般情况下这些也要放到EDT线程外执行的。即使你放到EDT内部，那也是checked exception给你了这个一个条件让你判断耗时是否小。

如果你通过点按钮测试EDT问题的话，那看来你确实没开发过大型桌面程序。
本地测试环境和正式运行环境（很可能是公网）的网速完全不一样，往往本地不卡的程序上线就卡死。