那请你举个当前context不知道如何处理的情况出来吧。

某个模块知道自己“哪些情况不知道如何处理”，这是个悖谬。

更通常的情况是，这个模块把一切它没考虑到的事情都throw出去了，把它不愿去考虑的事情也throw出去了。然后外层调用开始头痛。

[ 本帖最后由 wwwsq 于 2008-8-31 03:55 编辑 ]

很受用啊
两位继续辩论
这种高质量的辩论绝对欢迎

我就奇了怪了, 不说那么远, try  catch 怎么就隐藏了错误呢。
不过一种机制而已, 和返回值一样, 除了倾向于用try catch捕捉异常而不是正常的错误外, 又有什么区别呢(性能暂放一边)
至于不讲规矩几乎一定导致烂代码, 我倒不这么认为.
正所谓讲规矩未必产生高质量代码一样, 不讲规矩也未必就是很差. 至少我不认为我的代码质量比周围人差, 或许我周围的人都非常差或者我有眼不识泰山吧

这个是有道理的, 一个函数以返回值而不是异常提供给其他函数， 我非常赞同
不过函数内部我可以用异常阿, 本函数抛出的异常本函数解决, 还是在减少代码量与清晰度上有好处的。
至于内部实现而不是公共接口, 在不严重影响清晰度的情况下, 函数抛出异常我也不认为有什么大不了, 到底好处多还是坏处多， 具体问题具体分析， 见仁见智而已

try/catch 和 返回值在这个层面上来讲，不过是两种传递错误的方式。难道你的函数从来不返回错误值么？返回错误值后从来就不处理么？

不知道你是从来没写过代码，还是没有认真思考。

exception 是你throw的，没考虑到，你怎么throw？唯一的问题是下层throw出来的、应该在本层catch的异常可能会由于疏忽或不知道而没有捕捉。这就是我说的c＋＋中异常的问题之一：无法保证上层函数捕捉所有应该捕捉的异常。这方面感觉java的机制更好。但是就这方面而言，在C/C＋＋里采用返回值的方式传递错误并不比抛异常要好，实际上更糟糕（见下面的例子）。

用你的逻辑，采用函数返回值的方式同样有这问题？实际上所谓“越往上传就越不知道”那是因为已经传过头了。还是那句话，这就是我说的c＋＋中异常的问题之一：无法保证上层函数捕捉所有应该捕捉的异常。

假设这样一个程序：函数 fa 对于输入的每一条记录调用 fb 进行处理。fb又调fc，fc调fd。在fd中遇到错误，没法处理。fc也不知道，但是fb知道。来对比一下用exception和返回值两种方式吧：

1，理想情况下，异常由fd=>fc=>fb后，在fb中处理。
2，如果fb中忘了捕捉（我说的难点：没有机制保证fb一定回捕捉fd抛出的异常），由于fa中的预防措施，错误的影响被限制在一条记录以内，而且这个错误被记录下来。从site把数据取回后，通过重现和调试找到bug。
3，如果fa也没捕捉，exception一路往上，最终导致程序崩溃。在错误发生后，公司赔客户一大笔钱，然后由core文件很快找到bug。

再来看看用返回值的情况：

1，理想情况，错误仍然是 fd=>fc=>fb，然后在fb中处理。和采用exception没有区别，但是代码更难看些。
2，如果fb中忘了检查返回值，程序的错误就被隐藏下来
3，如果fa中忘了，错误同样也被隐藏下
4，还有在fc中也可能忘了。

错误被隐藏的后果，最好的情况是错误导致在后续的操作过程中崩溃。于是公司赔客户一大笔钱，然后去找bug。由于错误暴露的地方并非它发生的地方，找bug有可能要多花更多功夫。
更倒霉的情况是，系统静悄悄的继续运行下去。直到有一天终端用户投诉到客户那里。客户大为恼火，索赔更大一笔钱。因为没有错误日志，甚至连有多少条错误记录还得的费一番周折才能统计出来。另外，除了和上面一样找bug要多费些功夫外，还得再花额外的功夫去更正之前的错误。

除了上面说的，返回值还有个问题：有时候返回值不方便。比如说构造函数。再举一例：如何定义函数 str2int？ 一个自然的想法就是 int str2int(const string& str)。可是如果这样的话，返回值就无法表示错误了（就像atoi）。于是只能改成 int str2int(const string& str, int& output)。定义成这样的话，用起来就不方便了。例如

try { ret = str2int("120") + str2int("119");}catch (){}

就得写成：

int a,b,rc;
if ( (c = str2int("120", &a)) && (c = str2int("119", &b))) {
   ret = a + b;
} else {
}

最后，说明一点，我并不是想说c＋＋的异常机制很完美，或者说用异常才是“正确的”，不用是错误的。据说关于C++异常机制的争论很多，有些项目就禁用异常。它们应该自有其道理，我也很希望有真正比较了解c＋＋异常的人士出来剖析一下异常的缺陷。我只是想说本帖的那些反对异常的理由在我看来不成立。

[ 本帖最后由 lgfang 于 2008-9-2 21:18 编辑 ]

返回值是显式的、静态的，异常是隐式的、易变的。

我们这边有个规则，函数有返回值的那么调用者必须检查返回值。如果不知道返回值的含义，那么就查文档、查代码、问人。这个规则简单清晰，职责分明，很容易做到。

异常则是隐式的，而且易变的，缺乏清晰描述的。比如，一个函数int do_something(string s)本来可能会抛出十种异常（这十种异常各代表什么业务含义通常是没有文档说明的），上层函数随便猜测了这些异常代表的业务含义，东拼西凑之后总算通过了测试；在某次修改之后，这个函数变成可能会抛出十二种异常，上层调用怎么办？于是catch() throw;这样的代码就开始泛滥，一个exception可以从最底层抛到最顶层。

前面有位仁兄举了个例子，说有些非关键操作失败了要继续下面的关键步骤，这种事情要我来考虑到话，我会用一个socket connection往另外的进程发数据，让其他单独的进程来做非关键操作，既然是非关键操作就不要和关键操作混在一个进程里。

[ 本帖最后由 wwwsq 于 2008-9-3 17:10 编辑 ]

如果一个函数返回10种不同的返回值, 调用者检查这10种不同返回值作不同处理， 这自然是显式的、静态的
但怎么异常就变成是隐式的、易变的呢？
一个返回 int 型的函数可以返回 -1, -3, -n, 1, 2, n
一个抛出 int 的函数也可以抛出 -1, -3, -n, 1, 2, n， 而且我的catch代码照样能获得抛出的int的具体值，
这没有什么两样， 如果你说因为函数声明可以明确知道返回的是 int, 那么很显然, c++也有语法明确可以表示抛出什么异常, 语法是
例如:
void throw_int() throw (int){
    throw 47;
}
你可以说大家都不这么写, 问题是这是大家写不写的问题, 不能说异常的缺点, 就如函数如果没写返回值， 默认返回int型一样
反而, 一个函数可以抛出 int, char*, T型等各种异常, 返回值作不到吧。

这个不成理由, 如果一个函数返回了十个值, 不说东拼西凑了， 这显得主观; 在某次修改之后，这个函数变成可能会返回十二个值，上层调用怎么办， 如果你能回答出我的， 我就能回答出你的， 恩， 基本上自信可以使用大体相同的句式。

函数有返回值的那么调用者必须检查返回值， 这是人的规定， 不能作为异常的缺陷存在， 因为如果我也定义一个规矩如下:
函数有抛出异常的那么调用这必须检查异常。如果不知道异常的含义，那么就查文档、查代码、问人。这个规则简单清晰，职责分明，很 ...， 那么现在， 你告诉我， 你的认为返回值胜过异常的理由还存在么。

所以说异常返回值都是机制， 没什么谁好谁坏， 审时度势， 具体问题具体分析， 什么合适用什么， 仅此而已。
异常在一定意义上可能不如返回值层层传递来的规整， 但只要写代码的注意分寸即可， 而且这种不规整在一定情况下反而是其优势所在， 你可以说歪打正着, 呵呵， 着了就成了。 这就好比c++与c， 一群人骂c++一堆垃圾特性,问题是你认为垃圾的你可以不用嘛, c++又不是不能写纯c, 自然有用这些特性而且显得不垃圾的代码存在。
具体问题具体分析, 代码质量控制在自己手中而非c++手中, 仅此而已

[ 本帖最后由 zylthinking 于 2008-9-3 19:41 编辑 ]