What does this error mean? How can I fix it? This is the header code that's causing it:
class BadJumbleException : public exception {
public:
BadJumbleException (const string& msg); // Constructor, accepts a string as the message
string& what(); // Returns the message string
private:
string message; // Stores the exception message
};
And this is the source code:
BadJumbleException::BadJumbleException (const string& m) : message(m) {}
string& BadJumbleException::what() { return message; }
EDIT: This is the error:
looser throw specifier for 'virtual BadJumbleException::~BadJumbleException()
In C++03, per §18.6.1/5, std::exception has a destructor that is declared such that no exceptions can be thrown out of it (a compilation error will be caused instead).
The language requires that when you derive from such a type, your own destructor must have the same restriction:
virtual BadJumbleException::~BadJumbleException() throw() {}
// ^^^^^^^
This is because an overriding function may not have a looser throw specification.
In C++11, std::exception::~exception is not marked throw() (or noexcept) explicitly in the library code, but all destructors are noexcept(true) by default.
Since that rule would include your destructor and allow your program to compile, this leads me to conclude that you are not really compiling as C++11.
Related
In a code review recently, I had some less than kind words for something I thought awful. It turns out that it was obviously inspired by the QuantLib::Error class, which looks like this:
//! Base error class
class Error : public std::exception {
public:
/*! The explicit use of this constructor is not advised.
Use the QL_FAIL macro instead.
*/
Error(const std::string& file,
long line,
const std::string& functionName,
const std::string& message = "");
#ifdef QL_PATCH_MSVC_2013
/*! the automatically generated destructor would
not have the throw specifier.
*/
~Error() throw() override {}
#endif
//! returns the error message.
const char* what() const QL_NOEXCEPT override;
private:
ext::shared_ptr<std::string> message_;
};
Why is the member variable ext::shared_ptr<std::string> and not just plain std::string? What reason could there be to heap-allocate the string object itself? (The QuantLib code base seems to heap-allocate just about everything just about always just about everywhere, and pulls in shared_ptr's to cope with that - a classic anti-pattern - but doing it here as well "just for consistency" strikes me as a bit much. Am I missing something?)
This is following the behavior of standard library exception types.
They are supposed to be copyable without throwing exceptions, since throwing an exception during construction of an exception handler parameter would cause a call to std::terminate (and possibly in some other situations requiring a copy of the exception as well).
If std::string was used directly, copying the exception could cause for example a std::bad_alloc to be thrown. Using a reference-counted pointer instead avoids that.
What does this error mean? How can I fix it? This is the header code that's causing it:
class BadJumbleException : public exception {
public:
BadJumbleException (const string& msg); // Constructor, accepts a string as the message
string& what(); // Returns the message string
private:
string message; // Stores the exception message
};
And this is the source code:
BadJumbleException::BadJumbleException (const string& m) : message(m) {}
string& BadJumbleException::what() { return message; }
EDIT: This is the error:
looser throw specifier for 'virtual BadJumbleException::~BadJumbleException()
In C++03, per §18.6.1/5, std::exception has a destructor that is declared such that no exceptions can be thrown out of it (a compilation error will be caused instead).
The language requires that when you derive from such a type, your own destructor must have the same restriction:
virtual BadJumbleException::~BadJumbleException() throw() {}
// ^^^^^^^
This is because an overriding function may not have a looser throw specification.
In C++11, std::exception::~exception is not marked throw() (or noexcept) explicitly in the library code, but all destructors are noexcept(true) by default.
Since that rule would include your destructor and allow your program to compile, this leads me to conclude that you are not really compiling as C++11.
I am beginner in c++, and hence apologies for this silly question. I am posting it here because I cannot find a similar answer on stackoverflow.
I was progressing through exceptions in C++ and as I was doing some hands on with custom exceptions, I have this code
class MyException: public std::exception{
public:
virtual const char* what() const throw() {
return "something bad happened";
}
};
// class that throws above exception
class canGoWrong {
public:
canGoWrong(){
throw MyException();
}
};
The above code was shown by the teacher. The constructor just implemented a virtual function defined in the base class exception. I got till there.
Now when I was trying a different version to practice, I tried to use a custom function instead of re-defining the virtual (as c++ doesn't strictly enforce the concept of interface, please correct me if I am wrong here.)
I wrote it as
class my_custom_shit_exception: public std::exception {
public:
const char* show() { // I omitted the const throw() here
return "This is an error encountered\n";
}
};
class myclass {
public:
myclass() {
throw my_custom_shit_exception();
}
};
To summarise, I didn't find a difference in behaviour in both ways
public:
const char* show() {
return "This is an error encountered\n";
}
virtual const char* what() const throw() {
return "something bad happened";
}
So why was the const throw() used in the what() virtual function? What difference it makes?
Thanks to all.
The function signature
class std::exception {
//...
public:
virtual const char* what() const throw();
//...
};
can be read as: what is a virtual member function of std::exception which returns a pointer to a constant character (array) and which does not modify members of that object (hence the 2nd const) and which guarantees not to throw an exception in its code.
Beware that the exception-specification is nowadays deprecated: Instead, since C++11 there is the noexcept specifier to declare functions that "guarantee" not to throw exceptions. Additionally, since C++17 the throw() has become a synonym for noexcept(true), but with a slightly different behaviour.
For more details, refer to this description of noexcept.
There it also says: "Note that a noexcept specification on a function is not a compile-time check; it is merely a method for a programmer to inform the compiler whether or not a function should throw exceptions. The compiler can use this information to enable certain optimizations on non-throwing functions [...]".
I wanted to show some quotes from Scott Meyers
"Effective C++" Third Edition
int doSomething() throw(); // note empty exception spec.
This doesn’t say that doSomething will never throw an exception; it
says that if doSomething throws an exception, it’s a serious error,
and the unexpected function should be called. †
For information on the unexpected function, consult your favorite search engine or
comprehensive C++ text. (You’ll probably have better luck searching for set_unexpected,
the function that specifies the unexpected function.)
And from the "Effective Modern C++"
In C++11, unconditional noexcept is for functions
that guarantee they won’t emit exceptions.
If, at runtime, an exception leaves f, f’s exception specification is violated. With the
C++98 exception specification, the call stack is unwound to f’s caller, and, after some
actions not relevant here, program execution is terminated. With the C++11 exception specification, runtime behavior is slightly different: the stack is only possibly
unwound before program execution is terminated.
The difference between unwinding the call stack and possibly unwinding it has a surprisingly large impact on code generation. In a noexcept function, optimizers need
not keep the runtime stack in an unwindable state if an exception would propagate
out of the function, nor must they ensure that objects in a noexcept function are
destroyed in the inverse order of construction should an exception leave the function.
Functions with “throw()” exception specifications lack such optimization flexibility,
as do functions with no exception specification at all.
I was playing with c++ exceptions and I've tried throwing an anonymous exception like this:
throw class : public std::exception
{
virtual const char *what() const noexcept
{
return "Custom exception";
}
} ex;
However I'm getting the following error when trying to compile:
error: expected primary-expression before ‘class’
throw class : public std::exception
^
My compiler is gcc 5.2.1 on Linux x86_64.
How can I achieve the desired result?
This is not an answer per-se, but some important information what will help you going forward:
First, throwing an anonymous exception is unlikely to be useful. Exceptions are caught by their type. If you can't name the type, you can't catch the exception explicitly - only by its base, in which case you may as well have just thrown the base.
Second (and this is important):
There's rarely a good reason to derive from std::exception directly. You should derive from one of the exception types defined in <stdexcept>
these are:
std::runtime_error - indicating that some runtime condition makes it impossible to perform the service at the moment (such as a missing file).
std::logic_error - indicating that what was attempted will never be possible and the program is fundamentally in error in a way that could not be detected at compile time.
Handy reference here:
http://en.cppreference.com/w/cpp/header/stdexcept
You can't declare a class in a throw statement. Declare the class first (anonymously if you like, naming it via a typedef), then you can throw it.
Better is to name the exception class, but put it in the nameless namespace:
namespace {
class LocalException : public std::exception {
const char *what() const noexcept override {
return "Custom exception";
}
};
}
....
throw LocalException();
or, if you insist, you can create an object of anonymous class, and throw that.
static class : public std::exception {
const char *what() const noexcept override {
return "Custom exception";
}
} LocalExceptionObject;
....
throw LocalExceptionObject;
Edit If you create a typedef, somebody can copy it, and it names the same class. You have to create an object of the anonymous class, and then nobody can name it.
Having said that, I don't think having anonymous things is useful. Far better to declare the class in a nameless namespace (so you know it is private), and just use it.
I'm trying to write an exception class that needs to be thrown when a system call fails. The exception should have a developer message and the errno code, and it's what method should format the developer message along with the error code. The C way to do the formatting is snprintf, but I'm trying to avoid that. I tried defining a class member for the exception of type std::stringstream. However, that did not work since stringstream has a private copy constructor. Looking for an alternative I learned about Boost's format object. I tried using it and got a different error:
In file included from tun_device.cc:7:0:
system_error.h:9:7: error: looser throw specifier for ‘virtual SystemError::~SystemError()’
class SystemError : public exception
^
In file included from system_error.h:4:0,
from tun_device.cc:7:
/usr/include/c++/4.8/exception:64:13: error: overriding ‘virtual std::exception::~exception() throw ()’
virtual ~exception() _GLIBCXX_USE_NOEXCEPT;
The way to solve this was to define my own destructor:
~SystemError() throw() {
}
As I understand, this line specifies that the destructor of this exception should not throw any exceptions.
Here's the complete class:
class SystemError : public exception
{
public:
int m_errno;
const char * m_message;
SystemError(int err, const char * message) :
fmt("%1%: %2%") {
fmt % message % errno;
m_errno = err;
this->m_message = message;
}
const char * what() const throw(){
return fmt.str().c_str();
}
~SystemError() throw() {
}
private:
format fmt;
};
I have several questions:
First of all - Am I reinventing the wheel? Is already there a recommended C++ way to handle failed system calls?
Why does using the format class as a member of the exception forces me to override the default destructor?
Is there any pitfall I should be aware of now that I added my own destructor?
Is there a way to achieve what I want using only the standard C++ library?
Exception can be handled using the standard exception class or creating your own classes derived from std::exception class. Inheritance would be used when you would want to extend the already available functionality available using std::exception. So the decision is totally dependent on how you want design your application.
boost::format does not force you to override the destructor. If you notice you are deriving from std::exception and composing boost::format. std::exception destructor is declared as virtual and has a no throw nature.
virtual ~exception() throw();
When you leave out the destructor, compiler implicitly provides a destructor, but this destructor does not have no throw() nature, hence compile error:
format.cpp:5: error: looser throw specifier for âvirtual SystemError::~SystemError()â
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/exception:63: error: overriding âvirtual std::exception::~exception() throw ()â
When you provide a constructor but as:
~SystemError(); //since the base class std::exception has a destrutor with no throw, the child should also follow the same, and again in this case compile time error is received:
format.cpp:25: error: looser throw specifier for âvirtual SystemError::~SystemError()â
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/exception:63: error: overriding âvirtual std::exception::~exception() throw ()â
To resolve the error SystemError should define a destructor like this:
~SystemeError() throw();
Sample SSCCE code:
#include <iostream>
#include<boost/format.hpp>
class SystemError : public std::exception
{
public:
int m_errno;
const char * m_message;
SystemError(int err, const char * message) :
fmt("%1%: %2%") {
fmt % message % err;
m_errno = err;
this->m_message = message;
}
const char * what() const throw(){
return fmt.str().c_str();
}
~SystemError() throw() {
}
// ~SystemError() {
//
// }
private:
boost::format fmt;
};
int main(){
return 0;
}
Adding destructor is like taking responsibilities of your actions. Destructor could be used to clear any heap memory assigned in the class. Absence of destructor would lead compiler to provide an implicit destructor, which could be cause of issues in specific cases.
The compilation error will not be received if the class in discussion has primitive data types.