I am using VC2010, and write following code to test "set_unexpected" function.
#include <iostream>
#include <exception>
void my_unexpected_handler()
{
std::cout << "unexpected handler" << std::endl;
}
int _tmain(int argc, _TCHAR* argv[])
{
set_unexpected(my_unexpected_handler);
throw 1;
return 0;
}
However, "my_unexpected_handler" is never called(the string isn't printed to console, I tried to set breakpoint in my_unexpected_handler, didn't run into).
What's wrong with my code?
Thanks
Sorry, I misunderstood the unexpected exception. However, even if I change code to following
#include <iostream>
#include <exception>
void my_unexpected_handler()
{
std::cout << "unexpected handler" << std::endl;
}
void func() throw(int)
{
throw 'h';
}
int _tmain(int argc, _TCHAR* argv[])
{
std::set_unexpected(my_unexpected_handler);
func();
return 0;
}
It still doesn't work? That is, "my_unexpected_handler" isn't called.
You are likely doing nothing wrong. You are using visual studio 2010 and that compiler does not support exception specifications. Well, it will syntax check code using them, but will not check the exceptiontype at runtime.
see http://msdn.microsoft.com/en-us/library/wfa0edys(v=vs.100).aspx
This isn't generally considered a problem as exceptions specifications are generally considered not to be useful, and have in fact been deprecated in then c++11 standard
Since the function throwing the exception has no throw specification, the exception is expected. The unexpected exception handler, logically enough, handles only unexpected exceptions. Nothing makes this exception unexpected.
Related
In this simple use of C++ contracts, I get the error: no type named 'fail_fast' in namespace 'gsl'. Will try block throw the fast_fail exception or some other exception?
#define GSL_THROW_ON_CONTRACT_VIOLATION
#include <gsl/gsl>
#include <iostream>
int main(void)
{
try {
Expects(false);
}
catch(const gsl::fail_fast &e) {
std::cout << "exception: " << e.what() << '\n';
}
}
GSL_THROW_ON_CONTRACT_VIOLATION and gsl::fast_fail were removed from the Microsoft GSL starting with release v3.0.0. All contract violations result in a call to std::terminate unless you are building in kernel mode for MSVC where it invokes __fastfail.
Header file gsl_assert.h only defines gsl::fail_fast exception with GSL_THROW_ON_CONTRACT_VIOLATION defined. So it compiles now? – Serve Laurijssen
There was a period of time where gsl::fast_fail was defined only when GSL_THROW_ON_CONTRACT_VIOLATION was defined, however that was identified in #267 and subsequently fixed in #268.
I have written very simple program and expected to crash, and it crashes. Now, I have set terminate function, but it will not be called and program just crashed without calling this function.
I have test program both inside debugger/outside debugger, built in both debug/release mode, but showing same behaviour (at least no calling my terminate function). I am musing VS 2012 and Windows 10.
void func()
{
cout<<"Aah you threw exception"<<endl;
}
int main(int argc, char* argv[])
{
set_terminate(func); //setting terminate function
int *p = NULL;
*p =11;
cout<<*p; //this will throw exception
}
C++ is not Java! A signal (or trap) can be generated by dereferencing a nullptr, but it is not automatically translated in C++ exception. On a POSIX compliant system, you can try to use the signal function to catch a signal as proposed by Throwaway Account 3 Million. On Windows, you can try to use the C structured exception handling.
If you don't, and still generate such a trap, the standard just defines that as an Undefined Behaviour, and it commonly just abort the program immediately, bypassing any set_terminate, atexit or whatever function you planned to be call on a controlled termination of your program.
Use signal to catch segmentation errors:
#include <iostream>
#include <signal.h>
using namespace std;
void func(int signal) {
cerr << "Caught signal " << signal << endl;
}
int main() {
signal(SIGSEGV, func);
void (*p)() = NULL;
p();
}
From Linux I know that in case a C++ program throws an exception, the exception type and message are printed on the terminal while the program dies. On mac, however, the only thing you get is:
libc++abi.dylib: terminate called throwing an exception
Abort trap: 6
Of course I could run the program in a debugger, but that's usually much more overhead just to see the exception type and message.
Is there any way to enable exception type and message printing on mac with any magic command?
Edit: I know what the correct way is to handle such situations with exception handling. It is more out of curiosity to find out whether the linux behavior can be reproduced on mac.
If you want to guarantee the information of a C++ exception is printed to the console you can add a try/catch block in main() like below.
#include <exception>
#include <iostream>
int main(int argc, char* argv[])
{
try { return mymain(argc, argv); }
catch(std::exception& e)
{
std::cout << "Unhandled exception thrown: " << e.what() << std::endl;
}
}
#include "iostream"
#include "conio.h"
#include "exception"
#include "cstdlib"
using namespace std;
void myunexpected ()
{
cerr << "unexpected called\n";
throw 0; // throws int (in exception-specification)
}
void myfunction () throw (int)
{
throw 'x'; // throws char (not in exception-specification)
}
int main (void)
{
set_unexpected (myunexpected);
try
{
myfunction();
}
catch (int) { cerr << "caught int\n"; }
catch (...) { cerr << "caught other exception (non-compliant compiler?)\n"; }
getch();
return 0;
}
Output(When executed on Visual studio 2008):
caught other exception (non-compliant compiler?)
But, I was expecting the output to be:
unexpected called
caught int
NOTE: I executed this program on Visual Studio 2008.
Yes, as per the Standard the output should be[#1]:
unexpected called
caught int
gcc gives accurate result.
Note that, MSVC is notoriously buggy w.r.t handling exception specifications. Exception specifications are considered a failed experiment.
AFAIK, MSVC does not implement exception specifications, except for the empty ones (throw()/nothrow)
C++03 Standard:
[#1] 15.5.2 The unexpected() function [except.unexpected]
The unexpected() function shall not return, but it can throw (or re-throw) an exception. If it throws a new exception which is allowed by the exception specification which previously was violated, then the search for another handler will continue at the call of the function whose exception specification was violated....
I was just playing around with exceptions in the visual studio and with the above code I was expecting that since my exception specification doesn't mention anything the bad_exception should have been thrown. But what actually happens is the exception gets caught by the appropriate handler. Why so? Am i missing some setting or something in the IDE?
While i got stuck at above mentioned, Actually I was trying to find answer to the question,If i have a exception blank specification then what gets called?
the unexpected() method or a *bad_exception* will be thrown and if both in what order?
Here's the code.
#include "stdafx.h"
#include <stdio.h>
#include <exception>
#include <iostream>
using namespace std;
class A
{
public:
int i;
};
void myunexpected ()
{
cerr << "unexpected called\n";
}
void doSomething(void) throw();
void doSomething(void) throw()
{
A obj;
obj.i= 100;
throw obj;
}
int _tmain(int argc, _TCHAR* argv[])
{
set_unexpected (myunexpected);
try
{
doSomething();
}
catch (bad_exception be)
{
puts("Caught something");
}
catch (A &obj)
{
puts("Caught Integer");
}
return 0;
}
Regarding exception specification, Visual Studio is not standard-conforming.
While the empty exception specification is somewhat useful (but, as said, not properly implemented by VS), in general exception specifications are seen as an experiment that failed.
Basically, exception specifications are almost useless and in many compilers implemented different to what the standard states. Look at your compiler documentation for more information.
http://msdn.microsoft.com/en-us/library/wfa0edys(VS.80).aspx
I can imagine that this means in particular that the VS compiler will use the exception specification to avoid generating code required for stack unwinding and that in the event of an exception actually being thrown you will end up with undefined behavior.