C 使用异常

如果您的代码行为不确定，则可能会导致几乎任何事情发生，包括抛出例外。

Visual C 6(默认情况下(DID(默认情况下(将类似的OS级异常转换为C 异常，因为您在此处讨论。显然，它的效果不是很好 - 默认情况下，他们的较新编译器不做这样做。如果您真的想要这种行为，它们确实提供了一个编译器开关(例如/eha(，可以让您这样做 - 但大多数人可能不建议使用它。

Windows结构化的异常处理具有SetUnhandledExceptionHandler，它将让您捕获SEH例外，清理您捕获的例外情况，然后抛出C 例外，您认为适合表示发生了什么。但是，这是一个相当手动的过程(即，由您撰写类似Switch语句的内容来整理您捕获的结构化异常，并确定对此做出的C 例外(。

同样，在Linux上，您可以为各种信号设置处理程序，并响应它们。不过，您可能需要对此有些棘手。问题在于，POSIX信号是异步传递的，并且您在其中可以做的事情非常有限。信号处理程序本身几乎唯一的事情就是设置sig_atomic_t类型的标志，并且外部代码可以(在方便时(检查其值，如果设置为设置，则会引发异常。混合信号和例外通常是一项相当不平凡的事业。

就catch(...)而言，它只会捕获C 异常，因此，如果您将其与某种翻译一起使用以从结构化异常中创建C 异常，则只会捕获上述记忆问题之类的东西/信号。至于您可以在那里做什么：这确实非常有限。您无法获得有关发生的例外的任何信息。至少当我使用它时，这几乎是最后一件事，试图管理尽可能秩序地关闭的事情，仅仅是因为到达时，任何可能做任何更聪明的可能性

似乎对不同类型的错误感到困惑，因此这里有关于不同错误以及如何处理它们的解释。可能发生三种错误

1. 编译错误
2. 由于触发未定义行为而引起的运行时错误
3. 由于系统限制而引起的运行时错误

这是您对这三个

编译错误您的编译器是您的朋友。修复您的代码，但请尝试避免规避类型系统。

触发未定义的行为看起来您在代码中的某个地方遇到了这种问题。在这种情况下，您有一个运行时错误。您可能做了什么

1. 删除了无效的指针
2. 用零>执行整数部门
3. 使用了不支持的装配级指令
4. 通过了一个已释放的指针

要找到解决1-3之类的问题，您可以使用调试器。assert宏也很有用。请注意，可以通过未能检查分配系统资源是否失败的某些功能来引入类型1的问题。如果是这样，请参见由于系统限制而引起的运行时错误。

类型4的问题很难找到，因为您会在下一个malloc上注意到问题。在GNU/Linux上，通过valgrind运行程序是您最安全的选择。我对此一无所知。

由于系统限制而导致的运行时错误这是您使用异常的地方。您无法预见，用户指定的文件不存在，或者是以不可解码的方式编码的。或者，您尝试提出OpenGL，但是用户没有最新的图形驱动程序，或者您正在使用远程X11连接。为了"解决"这些问题，您检查系统级返回值，并通过例外纾困。