返回信息流无论是在项目还是自己练习，都没考虑过，异常在程序里面是什么位置哦？必需品么？
小伙伴们你们怎么看？
这是一条镜像帖。来源：北邮人论坛 / cpp / #74067同步于 2013/9/30
该镜像源已超过 30 天没有更新，可能在源站已被删除。
CPP机器人发帖
大家在coding的时候考虑异常么？
TheCambrian
2013/9/30镜像同步69 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
那异常处理在cpp程序里是个什么样的位置？
忽略么？
【 在 nuanyangyang 的大作中提到: 】
: 绝大多数异常都是致命的，少数能够处理。
和C++确实没什么关系，一定要说C++的话，只能提一下C++的异常处理有二进制兼容性问题，不同的编译器会实现成不同的二进制代码，所以要小心。
一般来说，能处理才处理。大部分自己不能处理的异常最好继续往外抛，让真正能处理这个异常的函数去处理。
很多java程序员会写这种程序：
try {
doSomething();
} catch (SomeException e) {
// TODO: Add exception handling
}
这样做只是因为不抓住异常，编译就通不过。但是这样是错误的：它的逻辑是“你已经成功地处理了这个异常，程序可以正常继续执行”。而事实上程序员什么也没做，错误并没有被恢复，继续执行只能错上加错。好在C++没有Checked Exception。
这样也不好
try {
writeFile();
} catch (SomeException e) {
cerr<<"ERROR: Cannot write file!"<<endl;
exit(1)
}
这就认定这个异常一定是无法恢复的了。一碰到，程序就退出了。可是万一这段代码只是一个更大的程序的一部分呢？可能更高层的代码是可以处理这个异常，换用别的策略的。
所以毕竟异常就是异常。总是能处理就不叫异常了。
【 在 TheCambrian 的大作中提到: 】
: 那异常处理在cpp程序里是个什么样的位置？
: 忽略么？
好吧，我是先看的RAII，然后从网上看到一篇关于异常的三境界，在此之前根本没关心过异常，最多只是返回错误，但是我觉得异常处理还是有必要考虑的，只要关于资源方面的东东，还是谨慎一点
【 在 nuanyangyang 的大作中提到: 】
: 和C++确实没什么关系，一定要说C++的话，只能提一下C++的异常处理有二进制兼容性问题，不同的编译器会实现成不同的二进制代码，所以要小心。
: 一般来说，能处理才处理。大部分自己不能处理的异常最好继续往外抛，让真正能处理这个异常的函数去处理。
: 很多java程序员会写这种程序：
: ...................
另外，“和C++确实没什么关系”，何解？
c里没异常处理，cpp有异常处理，为什么说和cpp没关系？
【 在 nuanyangyang 的大作中提到: 】
: 和C++确实没什么关系，一定要说C++的话，只能提一下C++的异常处理有二进制兼容性问题，不同的编译器会实现成不同的二进制代码，所以要小心。
: 一般来说，能处理才处理。大部分自己不能处理的异常最好继续往外抛，让真正能处理这个异常的函数去处理。
: 很多java程序员会写这种程序：
: ...................
我的意思是：异常处理机制是很多语言共有的，原则是一样的，并不限于C++。
【 在 TheCambrian 的大作中提到: 】
: 另外，“和C++确实没什么关系”，何解？
: c里没异常处理，cpp有异常处理，为什么说和cpp没关系？
java里所谓的异常处理也只是个摆设么？好奇怪
这样的话，要这个机制还有什么意思？
【 在 nuanyangyang 的大作中提到: 】
: 我的意思是：异常处理机制是很多语言共有的，原则是一样的，并不限于C++。
:
【 在 TheCambrian 的大作中提到: 】
: java里所谓的异常处理也只是个摆设么？好奇怪
不是。Java做得更极端：几乎所有的异常情况都用“抛出异常”这种形式报告，同时要求异常必须捕获，或者声明抛出。这就是所谓的“checked exception”，也就是说编译器会检查你是否捕获了异常。
但最明显的问题就是忽略了“绝大多数异常都是致命的”这一现实，并使得大量程序员用IDE自动生成“try { ... } catch (Exception e) { /* DO NOTHING */ }”这样的代码。
如果选择后者，也就是声明抛出，会有另一套问题：
interface CodeSource {
String getCode();
}
class FileCodeSource implements CodeSource {
@Override
public String getCode() throws IOException { // ERROR
File f = ...; // Open some file
String r = readFile(f); // Read file
return r;
}
}
class InternetCodeSource implements CodeSource {
@Override
public String getCode() throws URLException { // ERROR
URL u = ...; // Open some file
String r = download(u); // Read file
return r;
}
}
两个具体实现，因为使用了不同的底层库，所以抛出不同的异常。但是，“抛出什么异常”是Java里面函数签名的一部分。所以这两个实现都会报错，无法实现一个通用的接口。
可以这样：
class FileCodeSourceException extends RuntimeException { // 注意是RuntimeException，这个在编译时不会检查。
}
class FileCodeSource implements CodeSource {
@Override
public String getCode() {
try{
File f = ...; // Open some file
String r = readFile(f); // Read file
return r;
} catch (IOException e) {
throw new FileCodeSourceException(e);
}
}
}
但这其实就是去掉了checked exception。还不如让Java从一开始就没有checked exception更好。
看不懂，[ema17]中心意思是不是说java语言强制异常“异常必须捕获，或者声明抛出”？至于怎么处理强制规定？
最后还是要回归cpp啊，你让我这个只看过一个星期java的男银怎么理解这个例子啊啊啊……好痛苦[ema16]
【 在 nuanyangyang 的大作中提到: 】
:
: 不是。Java做得更极端：几乎所有的异常情况都用“抛出异常”这种形式报告，同时要求异常必须捕获，或者声明抛出。这就是所谓的“checked exception”，也就是说编译器会检查你是否捕获了异常。
: 但最明显的问题就是忽略了“绝大多数异常都是致命的”这一现实，并使得大量程序员用IDE自动生成“try { ... } catch (Exception e) { /* DO NOTHING */ }”这样的代码。
: ...................