|
锁定老帖子 主题：关于用异常控制程序流程的看法
精华帖 (3) :: 良好帖 (0) :: 新手帖 (5) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-07-26
最后修改：2011-07-26
引用 定义了太多的业务异常，然后依不同的业务情况去抛出它们，然后在方法的调用处捕获它们。个人一直觉的这是一种蛋疼的做法 。
引用 至少直到目前为止我还没在开发过程中发现非用异常做流程控制不可的理由。
只能说lz很初级，做过的系统都太小太简单，抑或是不知道异常究竟应该怎么用 |
| 返回顶楼 | |
|
发表时间：2011-07-27
我现在都是用try catch 来做流程的走向。。。。
|
| 返回顶楼 | |
|
发表时间：2011-07-27
首先说数据库 少用约束，这个真的没有发现。数据库如此强大，应该不是程序考虑的问题。其次，用异常来控制流程，很多时候效率会好，路线会清晰。太多的if case 也会使得程序流变的复杂。通过异常从函数返回和正常从函数返回，对于抛出异常的函数本身来说是没有什么区别的。所以异常控制应该是可取的一种方式，不过楼主分析的也很详细，支持一下。
|
| 返回顶楼 | |
|
发表时间：2011-07-27
注定又是一场争论，关注！
|
| 返回顶楼 | |
|
发表时间：2011-07-27
httpclient_bd 写道 完全难以接受。
效率根本不是理由，那些需要pool的东西稍稍优化一下， 就够上万次的throw了。 楼主你忽略了接口定义本身的明确的自解释性了。API设计语义很重要，并且Exception机制本身还有继承关系和checked\unchecked区分， 这些不是用error code以及带mask的errorcode能描述和实现的很好的。 枚举， 你会让维护人员生不如死的。 同意你的看法。 |
| 返回顶楼 | |
|
发表时间：2011-07-27
个人认为用返回值代替异常才是蛋痛的做法
|
| 返回顶楼 | |
|
发表时间：2011-07-27
FileInputStream类的read方法报告了“已到达文件末尾”的情况，但是，它并没有采用抛出异常的方式，而是返回了一个特殊值：-1。DataInputStream类的readInt()方法每次读取四个字节，然后将其解释为一个int型数据。当读到文件末尾时，readInt()方法将抛出EOFException。异常本来就会改变流程。只是不应该出现在正常流程中。当违反契约时，必须用异常。
|
| 返回顶楼 | |
|
发表时间：2011-07-28
cctype 写道 FileInputStream类的read方法报告了“已到达文件末尾”的情况，但是，它并没有采用抛出异常的方式，而是返回了一个特殊值：-1。DataInputStream类的readInt()方法每次读取四个字节，然后将其解释为一个int型数据。当读到文件末尾时，readInt()方法将抛出EOFException。异常本来就会改变流程。只是不应该出现在正常流程中。当违反契约时，必须用异常。
我赞同你的观点 |
| 返回顶楼 | |
|
发表时间：2011-07-28
最后修改：2011-07-28
有时候数据的约束条件特别多，不是一个pattern就能解决的，如果都采用数值或枚举，工作量太大了，不如统一用带消息的异常来代替，在回滚数据的同时还可以通知用户。至于抛出异常的资源消耗，可以忽略不计的吧。
|
| 返回顶楼 | |
|
发表时间：2011-07-28
最近加班太多，周日的时候我再回复诸位吧。
现在连回帖都没时间看了。 |
| 返回顶楼 | |
