|
锁定老帖子 主题：老掉牙的话题，java的异常处理。
精华帖 (1) :: 良好帖 (6) :: 新手帖 (12) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-03-19
pufan 写道 carlkkx 写道 走本地调用和远程调用一回事的路线的人本根不知道时间也是接口的一部分。
如何把时间放在接口内，传递Date？ 你没有理解我的意思，这里要表达的意思是：本地调用和远程调用你无法屏蔽差异，因为一个东西对外的接口其实并不仅仅是逻辑意义上的还有时间，出错可能性等等。因为这些东西的不同导致你处理不同，事实上你们的情况就是一个扭曲的状况，一方面你们的API想方设法想要屏蔽差异，结果至少执行时间的差异你们无法屏蔽，然后呢这种差异又导致上面所谓处理不同（比如不能放在EDT），结果你们又用是否有IOException来判断这种差异。你说扭曲不扭曲？ |
| 返回顶楼 | |
|
发表时间：2011-03-19
其实你举得关于checked exception的例子都是异常滥用。
|
| 返回顶楼 | |
|
发表时间：2011-03-19
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问题，特别是其他更加复杂的对象以及对象间的操作及调用封装的话情况更是如此。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 其实你举得关于checked exception的例子都是异常滥用。
异常的妙处在于可以与返回值同时存在！ 你还不明白的话我真无话可说了。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
我要再次重申：这里有个关键理念不知道你认同不认同：
你的模块就是完成定义的目标，如果完成不了就报告错误，至于错误报告之后的事是不是不应该多管闲事？ 如果你认同这个理念，那么checkedException就是错误的设计。 现在根据pufan兄的情况，我要再加一点，如果你认同这个理念但是还是用checkedException，说明你可能在滥用异常，即异常用于其他目的而不是异常本身的意义。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
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问题，特别是其他更加复杂的对象以及对象间的操作及调用封装的话情况更是如此。 别老是用大型这个词，这里你说的问题都是你想屏蔽一些你屏蔽不了的差异带来的。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
carlkkx 写道 API设计者要求你处理你就要处理
———————————————— 这就回到我上面说的根本理念上了： 这个理念的核心是：API设计者没有资格要求。 看我上面写的这句话： 异常处理的选择权永远在使用方，被使用方不能越俎代庖，被使用方的职责就是要么完成目标要么报告错误，除此以外不要多管闲事。 “这个理念的核心是：API设计者没有资格要求。”恰恰相反，API设计者完全有必要提醒你有非常重要的异常可能会抛出，你一定要处理。 “被使用方的职责就是要么完成目标要么报告错误”这句话有问题，还应包括“要么向上抛出”，就好比我刚才举的IOException。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
pufan 写道 carlkkx 写道 其实你举得关于checked exception的例子都是异常滥用。
异常的妙处在于可以与返回值同时存在！ 你还不明白的话我真无话可说了。 你现在也只是不承认滥用而已，你可能认为你这是妙用，但是你已经基本承认你举的checked exception已经不是异常本身的意义了。 |
| 返回顶楼 | |
|
发表时间：2011-03-19
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痛苦在来本帖也不迟。 |
| 返回顶楼 | |
