Uncatchable Exceptions? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

开发者_StackOverflow Improve this question

First, is there such a thing as an uncatchable exception in C++?

I've seen one 2005 microsoft kb article that discusses exceptions thrown in one DLL, that can't be caught in another DLL. It seems this was resolved with a hotfix, years ago, but I might be having that problem now - with Visual C++ 2008.

Specifically, based on a post-crash minidump file report, during a call to ::fgetpos I'm seeing this:

kernel32!UnhandledExceptionFilter+0x55b

Two things pop in my head. First I notice the designated catch block, located in a separate DLL from the calling DLL, did not capture the exception!!! Is this a recurrence of what that KB article describes? Second, I wonder if a kernel32 "unhandled exception" is something that a Visual C++ catch block is incapable of catching. I thought using a "catch-all" elipses would have been sufficient.

Is there something I'm missing?

---

A visual C++ catch block will only be capable of catching a C++ exception. kernel32!UnhandlesExceptionFilter is about the entire SEH exception range, which cover much much more than just C++ exceptions. For a brief introduction, this article is still fresh and accurate: A Crash Course on the Depths of Win32™ Structured Exception Handling.

While we're at it, you also need to cover /EHa and possibly _set_se_translator. And, of course, the obscure __try/__exception SEH C++ MSVC extensions.

---

You need to distinguish C++ exceptions and SEH exceptions. kernel knows nothing about C++ exceptions, and C++ catch() knows nothing (unless extended catch handling is enabled) about SEH. SEH exceptions are catched with block _try and _finally. Those are very different, and one should never mix them up.

---

For the sake of argument, say you only have 2 types of exceptions. Normal exceptions and framework exceptions. Framework exceptions can normally not be catched in a try/catch. Probably for c++ the most common is out-of-memory exceptions ( or any form of user-unhandled normal exception will go to the framework for handling as a framework exception).

When catching an exception you exchange the heap and stack, which requires more memory, which you cannot do when you have run out of memory. Also framework exceptions can not be catched and continue with the execution. You can only register listeners that handle (log) the exceptions and normally you have framework settings for how many seconds the framework keeps your application alive before it is killed (to allow you to log it)

So normal exceptions you can catch and continue. Framework exceptions allways kills your application, but you can log them with a special listener