Catching class exception

[Dave]

try
{
...
}
catch (exception e)
{
cout << e.what() << endl;
}

In the code above, e is caught by value rather than polymorphically (assume
that what was thrown is derived from exception). What does the Standard say
about whether or not the call to e.what() will do the right thing? Is it
guaranteed to work, guaranteed to not work or implementation defined?

Thanks,
Dave

 

[Victor Bazarov]

try
{
...
}
catch (exception e)
{
cout << e.what() << endl;
}

In the code above, e is caught by value rather than polymorphically (assume
that what was thrown is derived from exception). What does the Standard say
about whether or not the call to e.what() will do the right thing?

What do you mean by "the right thing"?

Is it
guaranteed to work, guaranteed to not work or implementation defined?

The 'what' member function returns some valid pointer. Displaying it
is what it's there for. What specifically it will return is defined
by the implementation. If you catch the base class like this, it will
return something "suitable for conversion and display", but not
necessarily meaningful. The code will definitely not call the derived
class' "what()" member.

V

 

[Dave]

What do you mean by "the right thing"?

By "the right thing", I'm asking if it will return a pointer to the string
that was used to construct the *derived* object as opposed to a pointer to
some other string. Is it guaranteed to work, guaranteed to not work or
implementation defined given that the base what() is being called?

 

[Victor Bazarov]

By "the right thing", I'm asking if it will return a pointer to the string
that was used to construct the *derived* object

What derived object? What string passed to construct it? std::exception
has *no idea* about them.

as opposed to a pointer to
some other string.

Of course it's a pointer to some other string. 'std::exception' has no
constructor that takes a C string or a C++ string.

Is it guaranteed to work, guaranteed to not work or
implementation defined given that the base what() is being called?

What guaranteed to work?

I write the class:

class Base {
public:
Base();
virtual ~Base();
virtual int getnumber() const { return 42; }
};

How in the world should *I* know that *you* derived from it and made
*your* class to be constructed with some other number, which *you*
intended to *your* overridden 'getnumber' to return?

Just think a bit before replying.

V

 

[Dave]

What derived object? What string passed to construct it? std::exception
has *no idea* about them.


Of course it's a pointer to some other string. 'std::exception' has no
constructor that takes a C string or a C++ string.


What guaranteed to work?

I write the class:

class Base {
public:
Base();
virtual ~Base();
virtual int getnumber() const { return 42; }
};

How in the world should *I* know that *you* derived from it and made
*your* class to be constructed with some other number, which *you*
intended to *your* overridden 'getnumber' to return?

Just think a bit before replying.

V

OK, I guess I have to spell this out for you...

The definition of class std::exception contains the following declaration:

virtual const char* what() const throw();

Now take class std::logic_error, which derives publicly from class
exception, as an example.

class logic_error *must* be constructed with a std::string (for later use by
what()), class exception *may not* be constructed with a std::string. It
may only be default or copy constructed.

The question comes down to where the string that what() uses lives. It can
live either in class exception or it can live in the classes derived from
exception. Where the string lives determines what happens when I catch a
class exception by *value* and therefore end up calling the *base* what().

If the std::string lives in class exception (i.e. class exception holds the
string for the derived classes and they inherit it), the right thing will
print out upon using what(). If each derived class is responsible for
holding its own "what" string, the right thing will not print out upon using
what().

In my mind, the behavior is implementation defined, bu tI was hoping to get
confirmation of that.

Just think a bit before replying.

 

[Victor Bazarov]

[...]
OK, I guess I have to spell this out for you...


The definition of class std::exception contains the following declaration:

virtual const char* what() const throw();

Now take class std::logic_error, which derives publicly from class
exception, as an example.

class logic_error *must* be constructed with a std::string (for later use by
what()),

"for later use" by WHOSE "what()"? It's a virtual function.

class exception *may not* be constructed with a std::string. It
may only be default or copy constructed.

The question comes down to where the string that what() uses lives. It can
live either in class exception or it can live in the classes derived from
exception. Where the string lives determines what happens when I catch a
class exception by *value* and therefore end up calling the *base* what().

If the std::string lives in class exception (i.e. class exception holds the
string for the derived classes and they inherit it), the right thing will
print out upon using what(). If each derived class is responsible for
holding its own "what" string, the right thing will not print out upon using
what().

Yes, you get it now!

In my mind, the behavior is implementation defined, bu tI was hoping to get
confirmation of that.

The Standard says NOTHING about all this, as I already told you.

Just think a bit before replying.

Get your own copy of the Standard and stop wasting our time.

V

 

[Dave]

[...]
OK, I guess I have to spell this out for you...


The definition of class std::exception contains the following declaration:

virtual const char* what() const throw();

Now take class std::logic_error, which derives publicly from class
exception, as an example.

class logic_error *must* be constructed with a std::string (for later use by
what()),

"for later use" by WHOSE "what()"? It's a virtual function.

class exception *may not* be constructed with a std::string. It
may only be default or copy constructed.

The question comes down to where the string that what() uses lives. It can
live either in class exception or it can live in the classes derived from
exception. Where the string lives determines what happens when I catch a
class exception by *value* and therefore end up calling the *base* what().

If the std::string lives in class exception (i.e. class exception holds the
string for the derived classes and they inherit it), the right thing will
print out upon using what(). If each derived class is responsible for
holding its own "what" string, the right thing will not print out upon using
what().

Yes, you get it now!

I got it all along. You did not understand what I was asking.

The Standard says NOTHING about all this, as I already told you.


Get your own copy of the Standard and stop wasting our time.

You are absolutely free to not respond to any question if you so choose.
Nobody has an obligation to provide an answer in this or any NG. Nobody can
waste your time but you.

 

[Efrat Regev]

I'm not sure if this is what you're asking, but Alexandrescu and Sutter
explain in "C++ Coding Standards" a rationale for throwing by value and
catching by reference.

HTH

 

[Andrey Tarasevich]

try
{
...
}
catch (exception e)
{
cout << e.what() << endl;
}

In the code above, e is caught by value rather than polymorphically (assume
that what was thrown is derived from exception). What does the Standard say
about whether or not the call to e.what() will do the right thing? Is it
guaranteed to work, guaranteed to not work or implementation defined?

This code will, of course, slice the exception object, i.e
'std::exception::what()' will be called, not the derived class'
'what()'. The string, pointer to which is returned by
'std::exception::what()', is implementation defined, which means that in
general case it will not "do the right thing".

In order to make it "do the right thing" the exception has to be caught
by reference.

 

[Old Wolf]

He obviously means, if the ... above contained 'throw
runtime_error("foo");', will "foo" be written to cout?

Of course it's a pointer to some other string. 'std::exception'
has no constructor that takes a C string or a C++ string.

Non-sequitur. std::exception could contain a string internally,
even though it has no constructor that takes one.

What guaranteed to work?

The above code example !

I write the class:

class Base {
public:
Base();
virtual ~Base();
virtual int getnumber() const { return 42; }
};

How in the world should *I* know that *you* derived from
it and made *your* class to be constructed with some other
number, which *you* intended to *your* overridden
'getnumber' to return?

The question is, is that a valid implementation for std::exception?
It would be easy to implement std::exception in a way that
does 'work'.

Just think a bit before replying.

You can't solve that one by thinking, without reading the
Standard. And if he should follow your suggestion and
not bother this newsgroup with questions, perhaps we should
shut down the newsgroup entirely?

 

[Victor Bazarov]

[...]
You can't solve that one by thinking, without reading the
Standard. And if he should follow your suggestion and
not bother this newsgroup with questions, perhaps we should
shut down the newsgroup entirely?

Look, the Standard is available, and we're here not to re-type or
copy/paste it into our answers. That's one. Second, I am fairly
certain that even in the absence of the Standard, the OP has some
sort of documentation describing the behaviour of the 'std::exception'
class, which undoubtedly says something about this. That's two.
Third, there is other documentation readily available on the Web,
which probably describes this just as well. If that all means we
need to shut down the newsgroup, then we need to shut it down.
*I* don't think so. But the OP's question was not about something
that cannot be figured out without the newsgroup.

And I still think that questions, answers to which can be found
elsewhere, should only be asked here after a bit of thinking. That
is what I suggested. And get off my case on this.

Now,

The question is, is that a valid implementation for std::exception?

Or course it is. The Standard says nothing about what 'what' should
return except that it's an NTBS suitable for conversion and display.

It would be easy to implement std::exception in a way that
does 'work'.

That is totally irrelevant.

 

[BigBrian]

[...]
You can't solve that one by thinking, without reading the
Standard. And if he should follow your suggestion and
not bother this newsgroup with questions, perhaps we should
shut down the newsgroup entirely?

Look, the Standard is available, and we're here not to re-type or
copy/paste it into our answers. That's one. Second, I am fairly
certain that even in the absence of the Standard, the OP has some
sort of documentation describing the behaviour of the 'std::exception'
class, which undoubtedly says something about this. That's two.
Third, there is other documentation readily available on the Web,
which probably describes this just as well. If that all means we
need to shut down the newsgroup, then we need to shut it down.
*I* don't think so. But the OP's question was not about something
that cannot be figured out without the newsgroup.

And I still think that questions, answers to which can be found
elsewhere, should only be asked here after a bit of thinking. That
is what I suggested. And get off my case on this.

That may all be true, but you don't have to be a jerk! The Standard
may not be understandable, or the OP may not have access to the
Standard, or any number of other reasons may exist why they're posting
the question to this newsgroup.

Now,
std::exception?

Or course it is. The Standard says nothing about what 'what' should
return except that it's an NTBS suitable for conversion and display.


That is totally irrelevant.

I could be completely wrong, but I believe the answer the OP is looking
for is that he needs to catch by reference so that the call to what()
behaves polymorphically instead of slicing the thrown object down to
std::exception.