I'm using SWIG to wrap a C++ library into both Java and Python. The Java side works fine, but I'm having an issue wrapping the code into Python, in particular when a IO exception is thrown, I get the following in python:
...
RuntimeError: _408aad4bde7f0000_p_std__ios_base__failure
swig/python detected a memory leak of type 'std::ios_base::failure *', no destructor found.
Here is the relevant place in my .i file:
%include "exception.i"
#include <stdexcept>
#include <ios>
#include <iostream>
%exception {
try {
$action
} catch (const std::exception &e) {
PyErr_SetString(PyExc_Exception, const_cast<char*>(e.what()));
}
catch(std::ios_base::failure &e) {
PyErr_SetString(PyExc_IOError, const_cast<char*>(e.what()));
}
}
Any ideas? For what it's worth, the io exceptions work as expected both in native C++ using the library and in SWIG-wrapped Java.
Probably way too late of an answer, but you're supposed to wrap exceptions like this
// http://www.swig.org/Doc1.3/Library.html#Library_stl_exceptions
%exception {
try {
$action
} catch (const std::exception& e) {
SWIG_exception(SWIG_RuntimeError, e.what());
}
}
That is also portable across languages and you don't need separate exception handling for Java and Python.
Related
If I run a simple app
#include <stdexcept>
int main() {
throw std::runtime_error("Hello World!");
}
with Windows CMD, the error message is not shown. How can I fix it?
Let's take a look at what throw does in C++ from the official Microsoft Docs.
In the C++ exception mechanism, control moves from the throw statement to the first catch statement that can handle the thrown type.
Note that this means throw does not actually output anything on its own — you'd have to catch it first, then output something. Also note that this means the throw will have to be surrounded by try if you want to do anything with the exception other than terminate the program (which throwing the exception will do on its own).
See below for an example of how to use throw properly.
#include <stdexcept>
#include <cstdio>
int main() {
try {
throw std::runtime_error("Hello World!");
} catch (const std::exception& e) {
puts(e.what());
}
}
The only thing guaranteed to happen when an exception escapes main is that the program stops.
To print the message of an exception you have to catch it and print the message
#include <stdexcept>
#include <cstdio>
int main()
{
try {
throw std::runtime_exception("Hello World!");
} catch (const std::exception& e) {
std::puts(e.what());
}
}
I'm using MinGW gcc (or g++) 7.1.0 on Windows 10.
Normally, throwing an std::runtime_error shows information like this:
terminate called after throwing an instance of 'std::runtime_error'
what(): MESSAGE
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
But the following code only shows the last two lines, and the what() information is lost:
#include <stdexcept>
using namespace std;
int main() {
try {
throw runtime_error("MESSAGE");
} catch (...) {
throw;
}
}
So the code above only outputs:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
The same thing happens if I replace ... with const exception&, const runtime_error& (or without const, without &, or without both).
As I know, throw; rethrows the current caught exception. So why isn't what() shown?
What makes you think that rethrowing exception discards the information given by 'what()'? You never inspect what what() returns after rethrowing. This application has requested... message is shown because you uncaught exception caused program to be terminated. what() content is not supposed to be printed automatically.
You can print value return by what() without any problem:
#include <stdexcept>
#include <iostream>
int main()
{
try
{
try
{
throw ::std::runtime_error("MESSAGE");
}
catch (...)
{
throw;
}
}
catch(::std::exception const & exception)
{
::std::cout << exception.what() << ::std::endl;
}
}
Is there a standard way to check whether construction of a new std::codecvt_byname succeeded?
I was experimenting with the following program:
// cl /nologo /Fetest_codecvt_byname.exe /EHsc test_codecvt_byname.cpp && test_codecvt_byname
// g++ -o test_codecvt_byname test_codecvt_byname.cpp && test_codecvt_byname
#include <cstdlib>
#include <iostream>
#include <locale>
#include <new>
#include <stdexcept>
int main()
{
try {
new std::codecvt_byname<wchar_t, char, mbstate_t>(".nonsense");
} catch (const std::exception& ex) {
std::cerr << "Error: " << ex.what() << std::endl;
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
libstdc++ on Windows apparently throws a std::runtime_error object if the named locale is unsupported. Microsoft Visual C++'s STL implementation, however, does not throw an exception.
Not knowing which C++ compiler will compile the code, how do I check whether construction of the new std::codecvt_byname succeeded? Alternatively, is there a way to check whether construction will be successful assuming no out-of-memory scenario?
Section [22.3.1.1.2], Class locale::facet, of the C++11 FDIS states:
For some standard facets a standard "..._byname" class, derived from it, implements the virtual function semantics equivalent to that facet of the locale constructed by locale(const char*) with the same name.
The Standard unfortunately does not require an exception to be thrown by the std::codecvt_byname constructor if the named locale is invalid, as does the explicit std::locale constructor locale(const char*). However, a work-around is to attempt to construct the locale and use_facet the codecvt facet instead of attempting to use std::codecvt_byname.
i am using a visual studio c++ compiler,& during my study on exception handling,i came across a number of features that can't be supported by visual c++ compiler,
like controlling the exceptions that can be thrown out of a function.
also i was unable to modify the functioning of terminate() using set_terminate() .
is it a specification too for visual c++ to modify terminate()?...& if so,then can anyone explain that why microsoft is creating these specifications in its compilers?...:-x
what do you mean you were unable to modify terminate
have you tried something like this ?
// set_terminate example
#include <iostream>
#include <exception>
#include <cstdlib>
using namespace std;
void myterminate () {
cerr << "terminate handler called\n";
abort(); // forces abnormal termination
}
int main (void) {
set_terminate (myterminate);
throw 0; // unhandled exception: calls terminate handler
return 0;
}
Don't try to run from VS. Compile and exec from command line.
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.