   Questions about determining throw specifiers in C++.
  Hello,I have questions about determining throw specifiers in C++.Question 1)Ok, so I create methods/functions in C++ and I need to accurately declare their throw specifiers.  My concerns are that their may be many different C++ objects/functions embedded inside the functions/methods you write (and nested).  So ... to accurately declare throw specifiers for the written functions/methods you need to know exactly what is thrown from EVERY C++ function/object within the written function.  This gets to be a hassle because you have to look EVERYTHING up.  Am I missing something here?  Is there a more simple way?   Question 2)Say you have a virtual abstract data type class method, for example:[source lang = "C++"]virtual void Bar() = 0;It has no function body so obviously it cannot throw an exception, but perhaps another class method of the same class needs to know what it will throw from the polymorphed version.  Different deriving objects could throw different things from their versions of Bar, so if I am correct, a class using a polymorphic function will not know what it will throw.  So, how does that interaction work? Question 3)Say I have the sample code below:classFoo{public:Foo(const std::string& desc)throw():Desc__(desc){}std::string Desc__;};Why does it compile if, in the event you pass a NULL value to the constructor, the constructor will throw despite being declared as throw()?Thank you for your help.Jeremy   
Quote:Question 1)Ok, so I create methods/functions in C++ and I need to accurately declare their throw specifiers. My concerns are that their may be many different C++ objects/functions embedded inside the functions/methods you write (and nested). So ... to accurately declare throw specifiers for the written functions/methods you need to know exactly what is thrown from EVERY C++ function/object within the written function. This gets to be a hassle because you have to look EVERYTHING up. Am I missing something here? Is there a more simple way? Yea. Don't bother. Most compilers ignore them except for the no-throw specifier, anyway.Quote:Question 2)Say you have a virtual abstract data type class method, for example:It has no function body so obviously it cannot throw an exception, but perhaps another class method of the same class needs to know what it will throw from the polymorphed version. Different deriving objects could throw different things from their versions of Bar, so if I am correct, a class using a polymorphic function will not know what it will throw. So, how does that interaction work? If a virtual function has a specification, overrides must have the same specification or a more specific one. Quote:Question 3)Say I have the sample code below:Why does it compile if, in the event you pass a NULL value to the constructor, the constructor will throw despite being declared as throw()?The specifiers don't prevent compilation. They simply state that unexpected() will get called if an unexpected exception propagates out.   ;  Thank you ... that helps.If anyone else has any input I would love to hear it.Jeremy   ;  Derive all your own exception classes from one or another subclass of std::exception, then you'll at least know that if a piece of code throws something it can be caught with std::exception&.I agree that throw specifiers are somewhat useless (except perhaps no-throw). Particularly in case of templated code where it is impossible to know what might throw what.   ;Quote:Original post by grill8If anyone else has any input I would love to hear it.A good read: http://www.gotw.ca/publications/mill22.htm.   ;Quote:Original post by the_eddQuote:Original post by grill8If anyone else has any input I would love to hear it.A good read: http://www.gotw.ca/publications/mill22.htm.Nice read, thanks.   ;Quote:Original post by jpetrieQuote:Question 3)Say I have the sample code below:Why does it compile if, in the event you pass a NULL value to the constructor, the constructor will throw despite being declared as throw()?The specifiers don't prevent compilation. They simply state that unexpected() will get called if an unexpected exception propagates out.Further to that, what is "pass a NULL value to (a) constructor (which accepts a const std::string&)" supposed to mean? And even if you accepted a pointer instead of a reference, dereferencing a passed-in NULL pointer wouldn't "throw", but invoke undefined behaviour.   