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.
Related
I'm using the clang x64 compiler on MacOS 10.12. I have the following code:
try {
throw CryptoPP::Exception(CryptoPP::Exception::OTHER_ERROR, "test");
} catch(CryptoPP::Exception &e) {
std::cout << "cryptopp" << e.what() << std::endl;
} catch(std::exception &e) {
std::cout << "std" << e.what() << std::endl;
}
The CryptoPP is build as static library. When I use it in in a executable application, it works as expected.
It gets problematic when I use the CryptoPP static library in a dynamic library. Inside the library, I have that exact code (i.e. the exception does not leave the library). However, the log shows
std test
Meaning that only the second catch did actually catch the exception. How is that possible?
I have read that one can call std::set_terminate() to use own function as global exception handler, which catches all unhandled exceptions.
Simplified code of my program:
#include <exception>
#include <stdexcept>
#include <iostream>
void my_terminate_handler()
{
std::cerr << "Terminate handler" << std::endl;
std::cin.get();
std::abort();
}
int main()
{
std::set_terminate(my_terminate_handler);
int i = 1;
i--;
std::cout << 1/i << std::endl;
return 0;
}
Why my_terminate_handler() never invoked? Both in VC++ 2013, 2015 RC and gcc++-4.8.
The terminate handler will be called if the program calls terminate. This can happen for various reasons - including an uncaught exception - but division by zero isn't one of those reasons. That gives undefined behaviour; typically, it raises a signal (not a C++ exception), and you'd need to install a signal handler, not a terminate handler, to catch that.
Because there is no uncaught exception in your code. Add one and it gets executed:
#include <exception>
#include <stdexcept>
#include <iostream>
void my_terminate_handler()
{
std::cerr << "Terminate handler" << std::endl;
}
int main()
{
std::set_terminate(my_terminate_handler);
throw "cake";
}
I find out there are an obviously different behaviors between boost::packaged_task and std::packaged_task. I had tested the boost version 1.55 and 1.56, and the c++11 compilers are Visual Studio 2013 and gcc(in XCode).
That is, the calling get() of the future generated from packaged_task::get_future() emits different exceptions.
Here is my simple code:
#include <boost/thread/future.hpp>
#include <future>
#include <iostream>
struct my_error {};
void throw_something()
{
throw my_error();
}
int main()
{
typedef boost::packaged_task<void> packaged_task;
packaged_task task(throw_something);
auto fu = task.get_future();
task();
try {
fu.get();
std::cout << "no exception" << std::endl;
}
catch (const my_error&) {
std::cout << "catch my_error" << std::endl;
} catch (const std::exception &e) {
std::cout << "catch std::exception: " << e.what() << std::endl;
} catch (...) {
std::cout << "catch unknown error" << std::endl;
}
std::system("pause");
return 0;
}
In Visual Studio 2013 the result is: catch std::exception: Unknown exception
and in gcc(in XCode) is: catch std::exception: std::exception
But if I changed the type of packaged_task to c++11 provided by Visual Studio 2013 or gcc, that's:
typedef std::packaged_task<void()> packaged_task;
The result becomes difference: catch my_error
I think std::packaged_task works correctly because I can catch the really type. Do I misuse boost::packaged_task?
A key difference could be that the standard library packaged_task might be statically linked, and the boost::thread version is linked in dynamically.
Throwing exceptions across dynamic library boundaries may not always work, especially when the sources weren't compiled with exactly the same compiler options.
You could
check that the libraries were compiled with the same flags
use the static version of Boost Thread library (BOOST_THREAD_STATIC, BOOST_ALL_NO_LIB might be related from a quick a google), See also http://www.boost.org/boost-build2/doc/html/bbv2/tutorial/linkage.html
I read a thoughtful series of blog posts about the new <system_error> header in C++11. It says that the header defines an error_code class that represents a specific error value returned by an operation (such as a system call). It says that the header defines a system_error class, which is an exception class (inherits from runtime_exception) and is used to wrap error_codess.
What I want to know is how to actually convert a system error from errno into a system_error so I can throw it. For example, the POSIX open function reports errors by returning -1 and setting errno, so if I want to throw an exception how should I complete the code below?
void x()
{
fd = open("foo", O_RDWR);
if (fd == -1)
{
throw /* need some code here to make a std::system_error from errno */;
}
}
I randomly tried:
errno = ENOENT;
throw std::system_error();
but the resulting exception returns no information when what() is called.
I know I could do throw errno; but I want to do it the right way, using the new <system_error> header.
There is a constructor for system_error that takes a single error_code as its argument, so if I can just convert errno to error_code then the rest should be obvious.
This seems like a really basic thing, so I don't know why I can't find a good tutorial on it.
I am using gcc 4.4.5 on an ARM processor, if that matters.
You are on the right track, just pass the error code and a std::generic_category object to the std::system_error constructor and it should work.
Example:
#include <assert.h>
#include <errno.h>
#include <iostream>
#include <system_error>
int main()
{
try
{
throw std::system_error(EFAULT, std::generic_category());
}
catch (std::system_error& error)
{
std::cout << "Error: " << error.code() << " - " << error.what() << '\n';
assert(error.code() == std::errc::bad_address);
}
}
Output from the above program on my system is
Error: generic:14 - Bad address
To add to the excellent accepted answer, you can enrich the error message with some contextual information in the 3rd argument, e.g. the failing file name:
std::string file_name = "bad_file_name.txt";
fd = open(file_name, O_RDWR);
if (fd < 0) {
throw std::system_error(errno, std::generic_category(), file_name);
}
Then when caught, e.what() will return, for example:
bad_file_name.txt: file not found
#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....