有人会在程序中try catch吗？

wwwsq

原帖由 zylthinking 于 2008-9-5 01:52 发表


恩， 你面对的就是一个你所说的50%以外的程序员， 另外， 你上个贴子误解我了， 我也误解你了， 所以把上个贴子重新编辑了。
而且， 说到底我们说的是机制问题， 不应该掺合程序员的修养怎样。

机制是和人性相关的：）

异常机制的“eat every exception”的能力，就给了人偷懒的机会，从而导致了代码质量的下降。虽然在很多情况下，catch(...)可以加快项目的“完成”时间。

如果异常机制不允许catch(...)，那么就不容易导致劣质代码。不过这样的异常机制会有人用吗？

zylthinking

第一， 我用；
第二， 返回值也不能就保证了不偷懒。

extern int open();

bool open_wrapper(){
    ....
    open();
    ....
    return true;
}
这样的代码不是稀罕物， 你说某人偷懒了没有

zylthinking

call, 2点了， 先睡觉， 什么事明天再说

wwwsq

原帖由 zylthinking 于 2008-9-5 02:00 发表
第一， 我用；
第二， 返回值也不能就保证了不偷懒。

extern int open();

bool open_wrapper(){
    ....
    open();
    ....
    return true;
}
这样的代码不是稀罕物， 你说某人偷懒了没有

open()有返回值而调用者不检查，这是很明确的错误，责任在调用者。检查代码的人可以毫不犹豫的说，这是错的。

catch(...)是多明显的错误就很难说了。因为无数的项目无数代码里面，有无数的catch(...)。异常机制的catch(...)设计出来就是给人用的，这就等于鼓励程序员不要细分各种异常。

你可以现在回头去看看自己项目组里面的代码，有多少catch(...)这样的代码。理论上每个catch(...)都应该是经过严格审核的，程序里面应该基本上没有catch(...)才对。可事实上没人会仔细审查每个catch(...)，也没人能够这样做。

项目里面catch(...)越多，程序犯业务错误的机会就越多，虽然程序看起来不会crash。

返回值机制可以杜绝“不检查返回值”的情况，因为返回值机制就是这么一个麻烦细致的机制，谁偷懒一目了然。
而异常机制无法杜绝“catch(...)”的情况，因为这套机制里面设计catch(...)就是给人用的。

[ 本帖最后由 wwwsq 于 2008-9-5 09:05 编辑 ]

dd33099

请参照微软MSDN有关与MSXML的用法，里面详细说明了在C++中使用try。。catch
不过你要懂COM，也就是抽象类（接口）的使用方法

zylthinking

原帖由 wwwsq 于 2008-9-5 08:48 发表




open()有返回值而调用者不检查，这是很明确的错误，责任在调用者。检查代码的人可以毫不犹豫的说，这是错的。

catch(...)是多明显的错误就很难说了。因为无数的项目无数代码里面，有无数的catch(... ...

讲道理要摆事实， 你不能老凭主观感觉说话。 你用红字来表明是 错误， 对， 就是错误， 我举的例子就是说就算返回值也是要犯错误的。

catch(...)是多明显的错误就很难说了： 这个见仁见智， 你说它不明显我也没办法， 我就说返回值也不明显， 虽然违心， 你也拿我没办法， 呵呵。

因为无数的项目无数代码里面，有无数的catch： 检查返回值得if语句大概也是无数吧。
不抬杠了， 谁也说不服谁， 倒是耽搁了睡觉好时间。

jchc

异常跟错误是不同概念。错误应防止，异常不可避免。

依赛特小子

try catch 是很好的.只要对对应的异常进行正确处理,应该是没有问题的.

lgfang

真是佩服zylthinking的耐性