|
锁定老帖子 主题：老掉牙的话题，java的异常处理。
精华帖 (1) :: 良好帖 (6) :: 新手帖 (12) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-03-20
我不知道大家是否看懂了我上面描述的权利关系，我认为很容易明白，如果你认同这个权利关系，那么checkedException的使用必然存在侵权行为。
|
| 返回顶楼 | |
|
发表时间：2011-03-20
你先把那个帖子好好看一遍再说
我告诉你，软件设计和现实一样有很多是基于契约，就像合同的甲方乙方，都可能存在互相侵入的条款,而且有时这是必要的，或者说有保护性的 脑子别那么死，这是那个帖子的一个回复，发帖的也应该是很有经验的开发者 引用 I favor RuntimeException too.
But, sometimes, I do miss checked exception when I forget to catch an exception that's supposed to be handled, or forget to "throws" a runtime exception (for documentation reason) 增加一个约束往往要增加不少成本，你应该多考虑设计者增加这个成本到底是用来解决什么问题 在那个帖子也有提到框架喜欢抛unchecked一个原因是因为框架异常实际客户代码根本搞不定，这样很多时候就不存在在某层恢复的可能性，这使得框架异常经常需要一直捅上去，所以check这时是种阻碍 但你构建自己的应用并不是这样，你这个层次搞不定的问题，可能必须要上面某一层搞定，所以安全的途径是通过固化机制强制执行 我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机 因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程 这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统 实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞 你所说的无非就是强暴和乱吞，当老板让你你做事你事先向老板提要求和明确风险措施的时候，你认为这也是强暴吗？这就叫事前报告，让调用者做充分准备，如果你的老板是个天才无所不知无所不记，自然这个报告和流程是不必要的 我说的对你来说你现在也不可能理解，逐渐体会吧 |
| 返回顶楼 | |
|
发表时间：2011-03-20
最后修改：2011-03-20
ppgunjack 写道 你先把那个帖子好好看一遍再说
我告诉你，软件设计和现实一样有很多是基于契约，就像合同的甲方乙方，都可能存在互相侵入的条款,而且有时这是必要的，或者说有保护性的 脑子别那么死，这是那个帖子的一个回复，发帖的也应该是很有经验的开发者 引用 I favor RuntimeException too.
But, sometimes, I do miss checked exception when I forget to catch an exception that's supposed to be handled, or forget to "throws" a runtime exception (for documentation reason) 增加一个约束往往要增加不少成本，你应该多考虑设计者增加这个成本到底是用来解决什么问题 在那个帖子也有提到框架喜欢抛unchecked一个原因是因为框架异常实际客户代码根本搞不定，这样很多时候就不存在在某层恢复的可能性，这使得框架异常经常需要一直捅上去，所以check这时是种阻碍 但你构建自己的应用并不是这样，你这个层次搞不定的问题，可能必须要上面某一层搞定，所以安全的途径是通过固化机制强制执行 我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机 因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程 这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统 实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞 你所说的无非就是强暴和乱吞，当老板让你你做事你事先向老板提要求和明确风险措施的时候，你认为这也是强暴吗？这就叫事前报告，让调用者做充分准备，如果你的老板是个天才无所不知无所不记，自然这个报告和流程是不必要的 我说的对你来说你现在也不可能理解，逐渐体会吧 你既然讲到契约，你却为什么不能体会这段话呢： 我对checkedException 非常的反对，非常的不喜欢，不仅仅是什么过于学院化不实用之类的，而是从理念上认为它是错误的，因为它颠倒了权利关系。 处理什么错误的选择权是调用者的，而不是被调用方的，API方只有说明权不能侵犯调用者的选择权。因为你是服务的一方，你居然干涉用户的的选择，你强买强卖。这完全是对调用方的侵权行为。 你当然有说明权和报告权，甚至这是你的责任，但是你没有强制调用方对错误处理的选择权。 |
| 返回顶楼 | |
|
发表时间：2011-03-20
最后修改：2011-03-20
carlkkx 写道 ppgunjack 写道 你先把那个帖子好好看一遍再说
我告诉你，软件设计和现实一样有很多是基于契约，就像合同的甲方乙方，都可能存在互相侵入的条款,而且有时这是必要的，或者说有保护性的 脑子别那么死，这是那个帖子的一个回复，发帖的也应该是很有经验的开发者 引用 I favor RuntimeException too.
But, sometimes, I do miss checked exception when I forget to catch an exception that's supposed to be handled, or forget to "throws" a runtime exception (for documentation reason) 增加一个约束往往要增加不少成本，你应该多考虑设计者增加这个成本到底是用来解决什么问题 在那个帖子也有提到框架喜欢抛unchecked一个原因是因为框架异常实际客户代码根本搞不定，这样很多时候就不存在在某层恢复的可能性，这使得框架异常经常需要一直捅上去，所以check这时是种阻碍 但你构建自己的应用并不是这样，你这个层次搞不定的问题，可能必须要上面某一层搞定，所以安全的途径是通过固化机制强制执行 我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机 因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程 这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统 实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞 你所说的无非就是强暴和乱吞，当老板让你你做事你事先向老板提要求和明确风险措施的时候，你认为这也是强暴吗？这就叫事前报告，让调用者做充分准备，如果你的老板是个天才无所不知无所不记，自然这个报告和流程是不必要的 我说的对你来说你现在也不可能理解，逐渐体会吧 你既然讲到契约，你却为什么不能体会这段话呢： 我对checkedException 非常的反对，非常的不喜欢，不仅仅是什么过于学院化不实用之类的，而是从理念上认为它是错误的，因为它颠倒了权利关系。 处理什么错误的选择权是调用者的，而不是被调用方的，API方只有说明权不能侵犯调用者的选择权。因为你是服务的一方，你居然干涉用户的的选择，你强买强卖。这完全是对调用方的侵权行为。 你当然有说明权和报告权，甚至这是你的责任，但是你没有强制调用方对错误处理的选择权。 而且失败的理念必然导致失败的实践，checkedexception产生的问题远远比对他的预期要多，C#写的程序质量就比java差？ 比开发高质量软件能和Eiffel比吗，Eiffel为什么是高质量恰恰是因为其严格契约式理念。checkedexception是混淆职责，而不是清晰职责。 |
| 返回顶楼 | |
|
发表时间：2011-03-20
我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机
因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程 这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统 实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞 ———————————————————— 这是你的问题，无论如何你都应该尽力不能让系统无声无息的完蛋，即使完蛋了，也要告知我完蛋了，如果你没有顶层未处理异常捕获器，你就没有这个机会。你看过很多软件即使完了，他也会告知你，有些还可能让你发送错误报告等等。照你这么弄的话直接就无声无息崩溃了。 因为你没有顶层未处理异常捕获器的习惯，所以你甚至不能理解或体会我说的倒追法。 |
| 返回顶楼 | |
|
发表时间：2011-03-20
你先把那个帖子好好看一遍再说
———————————— 我看了，这个帖子很早，那时这个争端可能还是比较火热的时候，从Java阵营来说拥护checkedexception可能还很多，但是时至今日别说其他阵营了，就是Java阵营曾经那些拥护者很多估计也幡然醒悟了，比如《Think in Java》的作者。 |
| 返回顶楼 | |
|
发表时间：2011-03-20
Java基本可以说是唯一个采用checkedexception的主流语言，如果它是一个优秀特性一个好的思想，怎么会弄来如此大的反对声，如此大的争议，别的语言可能早就竞相模仿了。还会受如此的冷落。垃圾回收是个好东西所以大量语言都支持，而checkedexception是一次失败的尝试。这个在我看来已经尘埃落定。
|
| 返回顶楼 | |
|
发表时间：2011-03-20
引用 checkedexception产生的问题远远比对他的预期要多
因为你没有顶层未处理异常捕获器的习惯，所以你甚至不能理解或体会我说的倒追法。 我说的已经很浅显了，checkedexception显然不是弊大于利的东西，更不是一无是处 你如果不懂辩证看这个问题说明遇到问题还不够多 |
| 返回顶楼 | |
|
发表时间：2011-03-20
就是Java阵营曾经那些拥护者很多估计也幡然醒悟了，比如《Think in Java》的作者。 ？？？
他是c++出身，你看看他怎么评价java异常吧 java异常是有瑕疵，这本书里面也说了，但不是针对unchecked还是checked |
| 返回顶楼 | |
|
发表时间：2011-03-20
ppgunjack 写道 引用 checkedexception产生的问题远远比对他的预期要多
因为你没有顶层未处理异常捕获器的习惯，所以你甚至不能理解或体会我说的倒追法。 我说的已经很浅显了，checkedexception显然不是弊大于利的东西，更不是一无是处 你如果不懂辩证看这个问题说明遇到问题还不够多 老马的哲学观我不鸟，所以不要和我说什么辩证，反正辩证是万精油。 你的显然是怎么来的。没有基础的显然。你至始至终没有正面回应我上面说了很多的契约式，权利观这些。 |
| 返回顶楼 | |
