Hello, I have some code that throws an exception through BOOST_THROW_EXCEPTION. The class derives from std::runtime_error. The thing is that my program crashes and doesn't catch the exception if I use this macro, but if I use a language throw it behaves correctly. Does anyone have a clue? My code doesn't spawn threads. Thanks in advance.
BOOST_THROW_EXCEPTION. The class derives from std::runtime_error.
The thing is that my program crashes and doesn't catch the exception if I use this macro, but if I use a language throw it behaves correctly.
To see what BOOST_THROW_EXCEPTION does exactly, read the following: http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTIO... http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
To see what BOOST_THROW_EXCEPTION does exactly, read the following: http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTIO... http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
I already read it. But I can't figure out why it segfaults at all. I have no idea.
2011/5/17 Germán Diago <germandiago@gmail.com>:
To see what BOOST_THROW_EXCEPTION does exactly, read the following: http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTIO... http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
I already read it. But I can't figure out why it segfaults at all. I have no idea.
I found the error. It had nothing to do with the macro. But I don't know wether this is a bug or not in class shared_ptr: I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"), &fclose); call. If fopen returns null I think that the custom deleter is still called even if the class was constructed with a null pointer. Maybe I should make sure myself that fopen doesn't return NULL, because, anyway when you construct a shared_ptr you are passing a valid resource and it is not checked.
I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"), &fclose); call.
If fopen returns null I think that the custom deleter is still called even if the class was constructed with a null pointer. Maybe I should make sure myself that fopen doesn't return NULL, because, anyway when you construct a shared_ptr you are passing a valid resource and it is not checked.
fclose is just a bad deleter that doesn't work correctly with NULL, but you can wrap it with your own deleter: void checked_fclose(FILE *f) { if (f) fclose(f); } shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"), &checked_fclose);
On Tue, May 17, 2011 at 6:11 AM, Germán Diago <germandiago@gmail.com> wrote:
2011/5/17 Germán Diago <germandiago@gmail.com>:
To see what BOOST_THROW_EXCEPTION does exactly, read the following: http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTIO... http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
I already read it. But I can't figure out why it segfaults at all. I have no idea.
I found the error. It had nothing to do with the macro. But I don't know wether this is a bug or not in class shared_ptr:
I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"), &fclose); call.
If fopen returns null I think that the custom deleter is still called even if the class was constructed with a null pointer. Maybe I should make sure myself that fopen doesn't return NULL, because, anyway when you construct a shared_ptr you are passing a valid resource and it is not checked.
Not a bug; a shared_ptr may hold ownership of an object even when shared_ptr::get() returns 0. You could use boost::shared_ptr<FILE> my_fopen( char const * name, char const * mode ) { if( FILE * f = fopen(name,mode) ) return boost::shared_ptr<FILE>(f,fclose); else BOOST_THROW_EXCEPTION(file_open_error()<< boost::errinfo_errno(errno) << boost::errinfo_api_function("fopen") << boost::errinfo_file_name(name) << boost::errinfo_file_open_mode(mode)); } Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (4)
-
Adam Romanek -
Emil Dotchevski -
Germán Diago -
Igor R