How can I catch an invalid fgetpos call as a C++ exception on Windows?

Question

In Visual C++ 2008, I want to "catch" an exception generated as shown here:

try {
    int foo = 20;
    ::fgetpos(0, (fpos_t*)&foo);
}
//...

Here are adjustments I've made to attempt a successful catch:

1. SEH is activated (/eha)
2. I've added a catch(...)
3. I've added a _set_se_translator vector.
4. I've added/adjusted to SEH syntax: __try / __except(EXCEPTION_EXECUTE_HANDLER)

In short, I've tried "everything in the book" and I still can't catch the exception. If I replace the call to ::fgetpos with int hey = foo / 0 then suddenly all of the above techniques work as expected. So the exception I'm dealing with from ::fgetpos is somehow "extra special."

Can someone explain why this ::fgetpos error seems uncatchable, and how to work around it?

update When executed in the VS IDE, the output window doesn't name an exception. All it says is this:

Microsoft Visual Studio C Runtime Library has detected a fatal error in MyProgram.exe.

Not very helpful. When I run the console app from the command line, I get a crash dialogue. The "problem details" section of the dialogue includes this information:

Problem Event Name: BEX
Exception Offset:0002fd30
Exception Code: c0000417
Exception Data: 00000000
Additional Information 1:69ad
Additional Information 2:69addfb19767b2221c8e3e7a5cd2f4ae
Additional Information 3:b1ff
Additional Information 4:b1ffca30cadddc78c19f19b6d150997f

Answer 1

Since the code in your dump corresponds to STATUS_INVALID_CRUNTIME_PARAMETER, try _set_invalid_parameter_handler

Answer 2

Most likely, the runtime catches it for you and issues a debug dialog without returning or propagating the exception- that is a CRT call and they may add whatever exception catching code in there they like. It's well within Visual Studio's rights to catch a hardware exception inside a library function, especially if you are running from within the IDE or in debug mode, then it is expected of the runtime.

Of course, when you divide by zero, then there is no library call here to write that extra catching code.