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]

Dave wrote:

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]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:2V*******************@newsread1.mlpsca01.us.t o.verio.net...

Dave wrote:

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"?

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?

> 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

[Victor Bazarov]

Dave wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:2V*******************@newsread1.mlpsca01.us.t o.verio.net...

Dave wrote:

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"?

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]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:br*******************@newsread1.mlpsca01.us.t o.verio.net...

Dave wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:2V*******************@newsread1.mlpsca01.us.t o.verio.net...

Dave wrote:

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"?

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

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]

Dave wrote:

[...]
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]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:rq*******************@newsread1.mlpsca01.us.t o.verio.net...

Dave wrote:

[...]
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.

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.

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.

V

[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
"Dave" <be***********@yahoo.com> wrote in message
news:10*************@news.supernews.com...

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

[Andrey Tarasevich]

Dave wrote:

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.

--
Best regards,
Andrey Tarasevich

[Old Wolf]

Victor Bazarov wrote:

Dave wrote:

"Victor Bazarov" wrote:

Dave wrote:

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

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"?

He obviously means, if the ... above contained 'throw
runtime_error("foo");', will "foo" be written to cout?
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.

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

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

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]

Old Wolf wrote:

[...]
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]

> Old Wolf wrote:

[...]
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,

> 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.

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.