|
锁定老帖子 主题：老掉牙的话题，java的异常处理。
精华帖 (1) :: 良好帖 (6) :: 新手帖 (12) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-03-19
pufan 写道 carlkkx 写道 API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 “这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。 “被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。 你凭什么认为我这一层就一定要处理？如果我处理不了怎么办，你的一定是哪来的？说到最后怎么又绕回这里了。这个自以为是的一定是哪来的？ |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 pufan 写道 carlkkx 写道 其实你举得关于checked exception的例子都是异常滥用。
异常的妙处在于可以与返回值同时存在！ 你还不明白的话我真无话可说了。 你现在也只是不承认滥用而已，你可能认为你这是妙用，但是你已经基本承认你举的checked exception已经不是异常本身的意义了。 恰恰就是异常本身的含义，一个可能抛出IOException的方法会被认为这有耗时的IO操作，一个自定义的业务异常代表着业务流程分支的选择。难道你认为异常就仅仅是错误吗，捕捉打印返回错误信息就足够了吗。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 pufan 写道 carlkkx 写道 API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 “这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。 “被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。 你凭什么认为我这一层就一定要处理？如果我处理不了怎么办，你的一定是哪来的？说到最后怎么又绕回这里了。这个自以为是的一定是哪来的？ 谁设计的API谁当然非常清楚API的实现以及后果，这就是凭据。你处理不了就往上抛，肯定有人处理的了，这已不是导致接口复杂的问题了，是一个重大的错误（分支、环境）必须得处理的问题。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
最后修改：2011-03-19
pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 其实你举得关于checked exception的例子都是异常滥用。
异常的妙处在于可以与返回值同时存在！ 你还不明白的话我真无话可说了。 你现在也只是不承认滥用而已，你可能认为你这是妙用，但是你已经基本承认你举的checked exception已经不是异常本身的意义了。 恰恰就是异常本身的含义，一个可能抛出IOException的方法会被认为这有耗时的IO操作，一个自定义的业务异常代表着业务流程分支的选择。难道你认为异常就仅仅是错误吗，捕捉打印返回错误信息就足够了吗。 异常是问题的描述，一个模块要么完成目标要么报告问题，而异常就是用来报告问题，问题抛上去后调用者怎么处理是有调用者决定的。你把异常用在了目标那一面了还说就是恰恰异常本身的含义？ |
| 返回顶楼 | |
|
发表时间：2011-03-19
pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 “这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。 “被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。 你凭什么认为我这一层就一定要处理？如果我处理不了怎么办，你的一定是哪来的？说到最后怎么又绕回这里了。这个自以为是的一定是哪来的？ 谁设计的API谁当然非常清楚API的实现以及后果，这就是凭据。你处理不了就往上抛，肯定有人处理的了，这已不是导致接口复杂的问题了，是一个重大的错误（分支、环境）必须得处理的问题。 你既然这么说你的一定就不攻自破了。那么你必须要回答checked exception给不能想处理的调用者带来的困扰怎么办？ |
| 返回顶楼 | |
|
发表时间：2011-03-19
pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 另外我的客户端如果要和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问题，特别是其他更加复杂的对象以及对象间的操作及调用封装的话情况更是如此。 别老是用大型这个词，这里你说的问题都是你想屏蔽一些你屏蔽不了的差异带来的。 建议你开发一些这种“大型”应用，体会各种业务逻辑在客户端本地计算导致的EDT痛苦在来本帖也不迟。 是你们自己设计到了这种境地，这种“大型”应用的地步，这样的运作模式。话说我们客户端计算也是很多的。我能想象你们在客户端可能维持大量的强类型的类型体系然后又都是checked exception，可想而知编程有多呆板麻烦。但也是你们自己设计到了这种大象境地。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 “这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。 “被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。 你凭什么认为我这一层就一定要处理？如果我处理不了怎么办，你的一定是哪来的？说到最后怎么又绕回这里了。这个自以为是的一定是哪来的？ 谁设计的API谁当然非常清楚API的实现以及后果，这就是凭据。你处理不了就往上抛，肯定有人处理的了，这已不是导致接口复杂的问题了，是一个重大的错误（分支、环境）必须得处理的问题。 你既然这么说你的一定就不攻自破了。那么你必须要回答checked exception给不能想处理的调用者带来的困扰怎么办？ 没有“不能想”，只有“必须得”，因为方法实现者是这么要求的。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 其实你举得关于checked exception的例子都是异常滥用。
异常的妙处在于可以与返回值同时存在！ 你还不明白的话我真无话可说了。 你现在也只是不承认滥用而已，你可能认为你这是妙用，但是你已经基本承认你举的checked exception已经不是异常本身的意义了。 恰恰就是异常本身的含义，一个可能抛出IOException的方法会被认为这有耗时的IO操作，一个自定义的业务异常代表着业务流程分支的选择。难道你认为异常就仅仅是错误吗，捕捉打印返回错误信息就足够了吗。 异常是问题的描述，一个模块要么完成目标要么报告问题，而异常就是用来报告问题，问题抛上去后调用者怎么处理是有调用者决定的。你把异常用在了目标那一面了还说就是恰恰异常本身的含义？ “完成目标要么报告问题”都是流程的一部分，正常流、异常流而已，业务异常产生业务流无可厚非。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 另外我的客户端如果要和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问题，特别是其他更加复杂的对象以及对象间的操作及调用封装的话情况更是如此。 别老是用大型这个词，这里你说的问题都是你想屏蔽一些你屏蔽不了的差异带来的。 建议你开发一些这种“大型”应用，体会各种业务逻辑在客户端本地计算导致的EDT痛苦在来本帖也不迟。 是你们自己设计到了这种境地，这种“大型”应用的地步，这样的运作模式。话说我们客户端计算也是很多的。我能想象你们在客户端可能维持大量的强类型的类型体系然后又都是checked exception，可想而知编程有多呆板麻烦。但也是你们自己设计到了这种大象境地。 必须得这样设计。要性能好，一个对象不仅仅有本地二级cache（硬盘），甚至还要有一级cache（内存）。就像浏览器的last modified，第二次刷新贼快的感觉很好滴。 呆板到谈不上，因为本来就是要在EDT外调用的，反而避免了很多程序员的疏忽。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 pufan 写道 carlkkx 写道 API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 “这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。 “被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。 你凭什么认为我这一层就一定要处理？如果我处理不了怎么办，你的一定是哪来的？说到最后怎么又绕回这里了。这个自以为是的一定是哪来的？ 谁设计的API谁当然非常清楚API的实现以及后果，这就是凭据。你处理不了就往上抛，肯定有人处理的了，这已不是导致接口复杂的问题了，是一个重大的错误（分支、环境）必须得处理的问题。 你既然这么说你的一定就不攻自破了。那么你必须要回答checked exception给不能想处理的调用者带来的困扰怎么办？ 没有“不能想”，只有“必须得”，因为方法实现者是这么要求的。 我写错了，是不能。看来我还是要怎么说，假设你是某API提供者，你说你可能抛出A，B，C三个异常，如果它们不是checked exception，调用者认为A他可以捕捉，B，C他无法处理，他对于BC不需要被强制做任何动作。这就是这个核心理念：抛出异常者只有告知的权力，没有强制的权力。你不能完全预期你被使用的场景。你的责任只是到你要么完成目标要么抛出异常，你只是说明你可能抛出的异常，你对上层没有强制权力。 |
| 返回顶楼 | |
