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

“这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。

“被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。

另外我的客户端如果要和server通信那是明确的，你要获得某个server的连接，但是这通常是被配置的，我们先不管这个，假设你获得了server的连接，那么你要和server通信怎么办呢？
连接上提供了足够的通信机制，我们看一下例子:

connection.requestRemoteService("服务名", para, new CommonMsgCallback() {

            public void onMessage(CommonMsg msg) {

            }

connection.requestRemoteService("服务名", para, new CommonMsgSwingCallback() {

            public void onSwingMessage(CommonMsg msg) {

            }

CommonMsg msg = connection.syncRequestRemoteService("服务名",para);

我想问一下你，在我举得例子里面，你会不知道你在和server通信吗？上面举得三个通信方法都是请求响应模式，其实还有一些变种可以指定这次通信的超时等。第一第二个都是异步的，第二个的好处是如果消息的回应处理需要设置到GUI，那么onSwingMessage已经是EDT线程安全的。
第三个就是同步请求响应。
当然connection还有注册监听模式的通信方式。再我目前构建Swing客户端世界里，我是难以想象一个人最后要通过异常来判断是不是一个耗时的操作。

你凭什么认为我这一层就一定要处理？如果我处理不了怎么办，你的一定是哪来的？说到最后怎么又绕回这里了。这个自以为是的一定是哪来的？

作为一个大型桌面应用来说，不仅仅与服务器通信这么一个api，更高层次的对象的获取增删改，以及在这之上的各种业务封装非常常见。举个例子吧：
City getCityByID(int id)这个方法，如果city是字典库设计（即完全本地内存cache）与非字典库设计（直接远程获取）在方法名上是看不出耗时的，不同过IO Exception提示的话，调用者很可能出EDT问题，特别是其他更加复杂的对象以及对象间的操作及调用封装的话情况更是如此。

谁设计的API谁当然非常清楚API的实现以及后果，这就是凭据。你处理不了就往上抛，肯定有人处理的了，这已不是导致接口复杂的问题了，是一个重大的错误（分支、环境）必须得处理的问题。

你既然这么说你的一定就不攻自破了。那么你必须要回答checked exception给不能想处理的调用者带来的困扰怎么办？

没有“不能想”，只有“必须得”，因为方法实现者是这么要求的。