使用结构化异常处理 (SEH) 的后果？
我看到 Doug Harrison 对使用（即捕获）结构化异常的“错误”做了很好的陈述（请参阅 问题#3）。但还有什么其他后果呢？例如，如果我有几个使用 /eha 编译的项目，与使用 /ehs 编译的其他项目混合在一起，会发生什么情况？库相互链接（编译时或运行时）时是否存在问题？
但这只是一个例子。还可能存在哪些其他问题？
I see Doug Harrison has made a good statement of what is "wrong" with using (i.e. catching) structured exceptions (see question #3). But what other consequences are there? For example, what happens if I have several projects compiled with /eha, mixed with other projects compiled with /ehs? Are there issues when the libraries are linked (compile time or run-time) with eachother?
But that is just one example. What other issues might there be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
/EHa 禁用优化。当 /EHs 生效时，如果编译器可以确保包装在 try {} 中的代码不会引发 C++ 异常，则编译器可以省略异常过滤器。这是 x86 和 x64 上的小空间优化，x86 上的小时间优化。问题是，如果捕获非 C++ 异常，则需要这些过滤器。结果是，当捕获此类异常而没有调用 C++ 对象的析构函数时，堆栈将被释放。不好，/EHa 避免了它。
混合不会导致链接器问题。从而导致上述问题。
是的，/EHa 也让 catch(...) 做了一件非常愚蠢的事情，它确实捕获了所有内容。不过，那艘沉船不久前就已经出航了，Pokemon C++ 异常处理也是一个坏主意。
/EHa disables an optimization. With /EHs in effect, the compiler can omit exception filters if it can be sure that no C++ exception is ever thrown by the code wrapped in a try {}. That's a small space optimization on x86 and x64, very small time optimization on x86. Problem is, those filters are needed if you catch non-C++ exceptions. The consequence is that the stack gets unwound when such an exception is caught without the destructor of a C++ object getting called. Not good, /EHa avoids it.
Mixing doesn't cause linker problems. It causes the above problem.
Yes, /EHa also makes catch(...) do a very stupid thing, it really catches everything. That ship wreck sailed a while ago though, Pokemon C++ exception handling is a bad idea too.