有人会在程序中try catch吗？

wwwsq

原帖由 vanny425 于 2008-8-22 16:10 发表
就让程序死掉?
如果运行的是一个7*24小时服务的程序，这种机制就严重了。

抛异常，然后异常得不到正确处理，也会造成很严重的问题：比如一笔订单被重复处理无数次，比如程序死循环的处理一个非法请求，比如程序占用了机器的所有内存和句柄。

错误就是错误，不要以为偷换成“异常”就万事大吉了。

zylthinking

原帖由 wwwsq 于 2008-8-22 16:51 发表



抛异常，然后异常得不到正确处理，也会造成很严重的问题：比如一笔订单被重复处理无数次，比如程序死循环的处理一个非法请求，比如程序占用了机器的所有内存和句柄。

错误就是错误，不要以为偷换成“异 ...

得不到正确处理, 无论用什么机制都会很严重的问题

wwwsq

原帖由 zylthinking 于 2008-8-22 18:02 发表


得不到正确处理, 无论用什么机制都会很严重的问题

因此问题变成：如何确保所有的问题都得到了正确处理。
比较保守的做法是：当程序知道自己在做什么的时候就继续做，如果程序不知道自己在做什么了那么就什么也不要做。
抛开语法和性能的角度而言，try_catch()会隐藏太多错误，仍然应该谨慎使用。

try_catch()主要是从降低开发成本而言有用的。很多错误被呼拉一下掩盖住了，比较适合软件按时交付，然后不断收费进行维护升级。
所谓测试驱动，是适合软件外包方式的。因为开发软件的人根本不关心软件有没有内在错误，只要能通过发包方所有的测试用例就可以了。而一款优秀的软件，应该从内在逻辑就是对的。

[ 本帖最后由 wwwsq 于 2008-8-28 16:17 编辑 ]

zylthinking

原帖由 wwwsq 于 2008-8-28 16:15 发表



因此问题变成：如何确保所有的问题都得到了正确处理。
比较保守的做法是：当程序知道自己在做什么的时候就继续做，如果程序不知道自己在做什么了那么就什么也不要做。
抛开语法和性能的角度而言，try_c ...

机制并不是确保问题得到了正确处理的前提。
原则也不是。
循规蹈矩自然看起来很理论很学院， 不过不守规矩也不是代码就惨不忍睹了。

wwwsq

原帖由 zylthinking 于 2008-8-30 14:35 发表


机制并不是确保问题得到了正确处理的前提。
原则也不是。
循规蹈矩自然看起来很理论很学院， 不过不守规矩也不是代码就惨不忍睹了。

你这话说了等于没说。
机制和原则当然不是"确保正确处理"的前提也不是唯一方法，但合理的机制和原则是保证软件质量的最好方法。
规矩有很多，有好的有烂的。烂规矩确实多半会导致烂代码，但是没有规矩几乎肯定会导致烂代码。
如何衡量一个开发总监的好坏？很重要的一点就在于，他设定的机制、原则、规矩是不是好的。
每个人所从事的领域都是有限的，从我的经验来看，隐藏错误总是会使系统在后期出现一些不容易发现的错误。
错误总是要付出代价的，不要心怀侥幸，错误越早修正代价越小。

隐藏错误适合什么场合呢，适合需要踢皮球的场合，适合需要推卸责任的场合。比如外包，比如关系紧张的跨部门开发。
你在自己的模块里面把所有的异常情况都隐藏了，其他模块就慢慢去找沉默的BUG吧。

lgfang

这个异常处理的局限是只能保证栈的状态，不能保证堆上的状态。如果出了异常，这个机制能够清理栈，堆要自己清理，这就很容易造成内存泄露。有什么好的办法能析构try期间创建在堆上的对象呢

我觉得最后的办法就是不要在堆上创建对象（对象内可以有成员变量指向在堆上创建的东西）。c＋＋一个很重要的技巧就Resouce acquisition is initinalization.它不仅对内存适用，基本上对所有资源都适用。

简单来讲基本上就是用局部对象把资源封装起来，在构造函数理申请资源，再析构函数里释放。这样即使出了异常，资源也会被释放。

wwwsq

原帖由 lgfang 于 2008-8-31 02:11 发表


我觉得最后的办法就是不要在堆上创建对象（对象内可以有成员变量指向在堆上创建的东西）。c＋＋一个很重要的技巧就Resouce acquisition is initinalization.它不仅对内存适用，基本上对所有资源都适用。
...

在构造函数里面不应该做太复杂的事情。在你的例子里，如果资源分配失败该怎么办？

lgfang

C++因为本身语言的特性，并不适合exception。Java、C#这样带垃圾回收、内存严格管理的语言，才是exception发挥作用的地方。

一直不明白java的垃圾收集有多大意义。不知道现在有没有变化。从几年前的老黄历来看，它似乎只能用于内存，别的资源的回收根本不能指望GC。因为什么时候回收根本不确定又没法控制。

lgfang

原帖由 wwwsq 于 2008-8-31 02:14 发表


正常逻辑和错误处理是没有明确分界的。比如用户填表单的时候某个应该填int的地方填了一个字符串过来，这是正常逻辑还是错误处理？

当然是错误处理。
但是错误处理不一定都要抛出异常。我认为如果当前context知道如何如何处理就处理了，不清楚的话才抛出异常让知道怎么处理这种情况的模块去处理。

以你的例子来讲：假设很不清楚如果收到一个字符串的话怎么处理的话就抛一个异常出去，如果很明确遇到这种情况就作为零，那么就可以直接处理了。

我想使用try/catch的难度在于如何确保上层的函数捕捉所有应该捕捉的异常。exception specification 似乎是想解决这个问题。不过我的感觉好像不是很有效。

[ 本帖最后由 lgfang 于 2008-8-31 02:49 编辑 ]

lgfang

原帖由 wwwsq 于 2008-8-31 02:16 发表



在构造函数里面不应该做太复杂的事情。在你的例子里，如果资源分配失败该怎么办？

以下是从c＋＋ 编程语言特别版（真是本好书，有人评价“这才是真正配得上‘c++编程思想'一名的书")摘录的建议：

[8] Throw an exception to indicate failure in a constructor; §14.4.6.
[9] Avoid throwing exceptions from copy constructors; §14.4.6.1.
[10] Avoid throwing exceptions from destructors; §14.4.7.
[13] Be sure that every resource acquired in a constructor is released when throwing an exception
in that constructor; §14.4