Visual Studio Exception settings ignored C++ - c++

I'm testing the assert method in C++ in Visual Studio 2017 and am getting an assertion exception as I would have expected. But after turning off all(!) exception settings I still get an exception thrown before it can be handled by my catch block (see below for an example).
try {
assert(validate(1363821) == false);
assert(validate(3848238) == true);
printf("Validation correctly implemented.");
} catch ( exception & e ){
const string error = e.what();
printf("Validation failed!");
}
So my questions are:
Am I doing something wrong here?
Or does the assert method throw some sort of exception which can't be handled by a catch block and will always generate a fatal exception? If so, how can one implement an assert method without creating fatal errors?
My exception settings are not set as is shown below:
Any help is greatly appreciated!

Assertion failure is not supposed to throw any exceptions. Instead it performs some implementation-specific report actions (such as printing an error message into stderr or showing that dialog) and then calls std::abort. So catch block and / or exception handling settings in IDE won't do anything in this situation. If you want assertion to throw an exception then you will need to write your own assert macro substitution.
If you are looking for some sort verification checking then you better utilize some dedicated framework, such as boost::test. Then you can write simply:
BOOST_AUTO_TEST_CASE(Doc_Parse_Empty)
{
BOOST_TEST(validate(1363821) == false);
BOOST_TEST(validate(3848238) == true);
}
It will also handle success/failure reporting automatically and seamlessly integrates into VS.

Related

How to trap an error in C++ when __try __except can't

I have code that uses a 3rd party library.
That library throws the occasional Access Violation exception. A basic try/catch didn't catch the error, and the program would hard crash.
I was able to use a __try __except instead, to catch the error, log it, and then gracefully exit the program.
The 3rd party has just updated their library, and now a small subset of the records that were causing the access violation errors just dies in production with "[program name] has stopped working"
In Visual Studio, when stepping thru I get "Microsoft Visual Studio C Runtime Library has detected a fatal error in [program name]."
I've updated my __except statement to catch everything (or so I believe), and it still happens.
Original __except:
__except (eps = GetExceptionInformation(), ((GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION)
? EXCEPTION_EXECUTE_HANDLER
: EXCEPTION_CONTINUE_SEARCH)) {
sprintf("error message");
result = 99;
}
New __except:
__except (eps = GetExceptionInformation(), ((1 == 1)
? EXCEPTION_EXECUTE_HANDLER
: EXCEPTION_CONTINUE_SEARCH)) {
sprintf("error message");
result = 99;
}
Just a friendly FYI, the first expression in your exception filter eps = GetExceptionInformation() appears to be unused.
Also, if you want to catch all exceptions then __except (EXCEPTION_EXECUTE_HANDLER) should be all you need. Although I would only recommend that for debugging purposes.
If this does not catch your exception, it is possible that the library is trying to handle the exception itself and something funky is going on in the library itself. I would check with the provider of the library and ask if this is a known issue.

How to throw the exception and catch it in the Node.js?

I am writing an ADD-ON using C/C++ in Node.js. For some reason, I need to throw the exception in C/C++ Add-on side, and to catch the exception in the JavaScript side.
JavaScript side:
try {
var conn = addon.get();
} catch(e) {
console.log("catching....................");
}
C/C++ code:
if (args.Length() <= 1 && !args[1]->IsFunction()) {
ThrowException(Exception::TypeError(String::New("Arguments 1 expect a function!")));
}
The actual behavior is:
For WIN:
A dialog pop-ups and shows:
Microsoft Visual C++ Runtime Library
Assertion failed!
Program: ...verMananger\src\wrapper\build\Release\nodedb2.node File:
c:\users\ibm_admin.node-gyp\0.10.1...\node_ob..._wrap.h Line: 60
Expression: !handle.IsEmpty()
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts
(Press Retry to debug the application - JIT must be enabled)
Abort Retry Ignore
For Linux:
node: /root/.node-gyp/0.10.9/src/node_object_wrap.h:60: static T*
node::ObjectWrap::Unwrap(v8::Handle) [with T =
NodeDB2Connection]: Assertion `!handle.IsEmpty()' failed.
How to throw the exception and catch it in the Node.js? Did everybody meet the same problem as I met?
Everything looks good, except you are not returning anything. Throwing an exception up to node is not the same as a regular C++ exception. All you need to do is add the follwoing line after your call and you should be good:
return scope.Close(Undefined());
So everything would look like this:
if (args.Length() <= 1 && !args[1]->IsFunction()) {
ThrowException(Exception::TypeError(String::New("Arguments 1 expect a function!")));
return scope.Close(Undefined());
}

How is it possible to know what caused an exception

In the code I am implementing I have
__except(EXCEPTION_EXECUTE_HANDLER)
{
return false;
}
And there is an execution path when the exception occurs
How can I know why the exception happened while debugging?
Use GetExceptionInformation?-Can it print the exception or give me exception`s data?
In Visual Studio, you can go to Debug > Exceptions (in the menu). There's a checkbox for each exception type which enables you to break execution when the exception is thrown.

Enabling exceptions in iOS

I have enabled GCC_ENABLE_CPP_EXCEPTIONS, GCC_ENABLE_EXCEPTIONS, GCC_ENABLE_OBJC_EXCEPTIONS in my XCode project. When I add the following lines of code to my source my program crashes with the forrlowing error: terminate called throwing an exceptionProgram received signal: “SIGABRT”.:
try {
throw 1;
}
catch (...) {
// handle
}
Shouldn't I be able to catch this exception? Do I have to do something more?
This page may help. From the information there, my thought would be either the -fexcpetions parameter is not explicitly passed, or your file is not being recognised as C++ source (.mm/.cpp).

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

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:
SEH is activated (/eha)
I've added a catch(...)
I've added a _set_se_translator vector.
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
Since the code in your dump corresponds to STATUS_INVALID_CRUNTIME_PARAMETER, try _set_invalid_parameter_handler
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.