User-defined exceptions

[Dave]

Hello all,

Unfortunately, the reference I have is a bit slim on describing how to
create user-defined exceptions derived from std::exception. I think what I
have below will work, but is it the way the mechanism was intended to be
used?

Thanks,
Dave

class cyclic_t: public std::exception
{
public:
cyclic_t(const std::string &what_param) : what_str(what_p aram) {}
virtual const char *what() const throw() {return what_str.c_str( );}

private:
std::string what_str;
};

[Andrey Tarasevich]

Dave wrote:

...
Unfortunately, the reference I have is a bit slim on describing how to
create user-defined exceptions derived from std::exception. I think what I
have below will work, but is it the way the mechanism was intended to be
used?
...
class cyclic_t: public std::exception
{
public:
cyclic_t(const std::string &what_param) : what_str(what_p aram) {}
virtual const char *what() const throw() {return what_str.c_str( );}

private:
std::string what_str;
};
...

In many cases this is an acceptable approach. But keep in mind such
things as:

1. 'std::string' is a class that allocates dynamic memory, which means
that this particular approach to implementing custom exceptions is not
appropriate for implementing, for example, "out of dynamic memory"
exceptions. In more general words, it is certainly a good idea to
implement exception classes so that they don't try to throw exceptions
themselves. You exception class doesn't follow this recommendation.

2. The implicitly declared destructor for your exception class will have
"unlimited" exception specification (because of 'std::string's
destructor), while 'std::exception ' destructor's exception specification
is 'throw()'. In C++ the derived class' virtual method is not allowed to
have exception specification that is wider than corresponding base class
virtual method's exception specification. Your code is ill formed,
because it violates this requirement.

--
Best regards,
Andrey Tarasevich

[Dave]

"Andrey Tarasevich" <an************ **@hotmail.com> wrote in message
news:vs******** ****@news.super news.com...

Dave wrote:

...
Unfortunately, the reference I have is a bit slim on describing how to
create user-defined exceptions derived from std::exception. I think what I have below will work, but is it the way the mechanism was intended to be
used?
...
class cyclic_t: public std::exception
{
public:
cyclic_t(const std::string &what_param) : what_str(what_p aram) {} virtual const char *what() const throw() {return what_str.c_str( );}
private:
std::string what_str;
};
...

In many cases this is an acceptable approach. But keep in mind such
things as:

1. 'std::string' is a class that allocates dynamic memory, which means
that this particular approach to implementing custom exceptions is not
appropriate for implementing, for example, "out of dynamic memory"
exceptions. In more general words, it is certainly a good idea to
implement exception classes so that they don't try to throw exceptions
themselves. You exception class doesn't follow this recommendation.

2. The implicitly declared destructor for your exception class will have
"unlimited" exception specification (because of 'std::string's
destructor), while 'std::exception ' destructor's exception specification
is 'throw()'. In C++ the derived class' virtual method is not allowed to
have exception specification that is wider than corresponding base class
virtual method's exception specification. Your code is ill formed,
because it violates this requirement.

--
Best regards,
Andrey Tarasevich

Wow, your second points brings up something really interesting! What you
are saying makes perfect sense. Yet when I look at the Standard, I see
standard exceptions that don't explicitly state that their destructor has an
exception specification of throw (). For example, consider 19.1.1. Is this
a problem with the Standard?????

Along the same lines, I see that the standard exception classes also use
std::string to specify what what will return(). These standard exception
classes also seem to be throwing caution to the wind with regard to your
first point too!

I hope we can get a good thread started on this. I'd love to hear what
people have to say and get this hammered out...

Thanks!
Dave

[Andrey Tarasevich]

Dave wrote:

...
In many cases this is an acceptable approach. But keep in mind such
things as:

1. 'std::string' is a class that allocates dynamic memory, which means
that this particular approach to implementing custom exceptions is not
appropriate for implementing, for example, "out of dynamic memory"
exceptions. In more general words, it is certainly a good idea to
implement exception classes so that they don't try to throw exceptions
themselves. You exception class doesn't follow this recommendation.

2. The implicitly declared destructor for your exception class will have
"unlimited" exception specification (because of 'std::string's
destructor), while 'std::exception ' destructor's exception specification
is 'throw()'. In C++ the derived class' virtual method is not allowed to
have exception specification that is wider than corresponding base class
virtual method's exception specification. Your code is ill formed,
because it violates this requirement. ...
Wow, your second points brings up something really interesting! What you
are saying makes perfect sense. Yet when I look at the Standard, I see
standard exceptions that don't explicitly state that their destructor has an
exception specification of throw (). For example, consider 19.1.1. Is this
a problem with the Standard?????

No, there's no problem here. Firstly, take a look at 18.6.1. The
declaration of the destructor of 'std::exception ' _does_ explicitly
include an exception specification. And it is 'throw()', exactly as I
said above.

As for the other standard exception classes (such as 'std::logic_err or'
in 19.1.1), I still don't see any problem here. They all inherit from
'std::exception ' and nowhere in the standard it says that their
destructors have exception specification different from the one that
'std::exception ::~exception()' has - that would be simply illegal
because that would violate 15.4/3.

Note also, that when user defined class declares no destructor, the
implicitly declared one will have exception specification derived in
accordance with the rules described in 15.4/13. It's the combination of
15.4/13 and 15.4/3 is what makes your code ill-formed. But I never said
it is hopeless. You _can_ have a data member of 'std::string' type
inside your 'std::exception '-derived class, but first you have to take
one or more steps in order to make your code well-formed and relatively
safe.

Firstly, you have to provide an explicit declaration of your class'
destructor with explicit exception specification. For example

class cyclic_t : public std::exception
{
...
~cyclic_t() throw()
{}
...
}

Now the code is well-formed already and should compile. However, if
during the destruction of a 'cyclic_t' object the destructor of
'what_str' subobject suddenly thrown an exception, the control will go
into 'std::unexpecte d' and you know what happens next. If such behavior
is unacceptable in your case, you have to take another step - provide a
function-level try-block for 'cyclic_t's destructor which will intercept
such exceptions.

That's probably what standard exception classes would do if they wanted
to contain an 'std::string' object as an immediate subobject.
Along the same lines, I see that the standard exception classes also use
std::string to specify what what will return(). These standard exception
classes also seem to be throwing caution to the wind with regard to your
first point too!
I don't see any evidence of that either. These classes accept
'std::string's as their constuctor's parameters. That doesn't
necessarily mean that they _store_ 'std::string's as subobjects. And
even if they do, there's still a way to do it relatively safely, as I
explained above. Moreover, using 'std::string' as a member subobject
could be perfectly reasonable in such exception classes as
'std::logic_err or', 'std::range_err or' etc. But I would be extremely
surprised if 'std::bad_alloc ' contained a data member of 'std::string' type.
I hope we can get a good thread started on this. I'd love to hear what
people have to say and get this hammered out...

I think you can find quite a lot of information on this topic if you
google for it of just read the relevant articles on GotW site.

--
Best regards,
Andrey Tarasevich

[Peter Koch Larsen]

"Andrey Tarasevich" <an************ **@hotmail.com> skrev i en meddelelse
news:vs******** ****@news.super news.com...

Dave wrote:

...
Unfortunately, the reference I have is a bit slim on describing how to
create user-defined exceptions derived from std::exception. I think what I have below will work, but is it the way the mechanism was intended to be
used?
...
class cyclic_t: public std::exception
{
public:
cyclic_t(const std::string &what_param) : what_str(what_p aram) {} virtual const char *what() const throw() {return what_str.c_str( );}
private:
std::string what_str;
};
...

[snip]
2. The implicitly declared destructor for your exception class will have
"unlimited" exception specification (because of 'std::string's
destructor), while 'std::exception ' destructor's exception specification
is 'throw()'. In C++ the derived class' virtual method is not allowed to
have exception specification that is wider than corresponding base class
virtual method's exception specification. Your code is ill formed,
because it violates this requirement.

--
Best regards,
Andrey Tarasevich

Hi Andrey

I believe you are a bit academic here. I can not imagine std::string's
destructor throwing. This would be very bad design and imply that lots of
normal stuff would be unable to work. As an example,
std::vector<std ::string> would be a no-no.

Actually, I do not believe that any well-designed class would EVER throw in
its destructor.... far too much code depends on this not ever happening.

Kind regards
Peter Koch Larsen

[Andrey Tarasevich]

Peter Koch Larsen wrote:

"Andrey Tarasevich" <an************ **@hotmail.com> skrev i en meddelelse
news:vs******** ****@news.super news.com...

Dave wrote:

> ...
> Unfortunately, the reference I have is a bit slim on describing how to
> create user-defined exceptions derived from std::exception. I think what I > have below will work, but is it the way the mechanism was intended to be
> used?
> ...
> class cyclic_t: public std::exception
> {
> public:
> cyclic_t(const std::string &what_param) : what_str(what_p aram) {} > virtual const char *what() const throw() {return what_str.c_str( );} >
> private:
> std::string what_str;
> };
> ...

[snip]

2. The implicitly declared destructor for your exception class will have
"unlimited" exception specification (because of 'std::string's
destructor), while 'std::exception ' destructor's exception specification
is 'throw()'. In C++ the derived class' virtual method is not allowed to
have exception specification that is wider than corresponding base class
virtual method's exception specification. Your code is ill formed,
because it violates this requirement.

--
Best regards,
Andrey Tarasevich

Hi Andrey

I believe you are a bit academic here. I can not imagine std::string's
destructor throwing. This would be very bad design and imply that lots of
normal stuff would be unable to work. As an example,
std::vector<std ::string> would be a no-no.

Actually, I do not believe that any well-designed class would EVER throw in
its destructor.... far too much code depends on this not ever happening.
...

Well, I could be a bit academic in my first point, but not in the second
one. The bottom line is that this code is ill-formed. It does not
compile. Even if 'std::string's destructor does not actually throw
anything, it still has unlimited exception specification. This
immediately causes the implicitly declared destructor of class
'cyclic_t' to have unlimited exception specification (see 15.4/13),
which in turn will violate the requirements 15.4/3.

For some reason Comeau only issues a warning about this problem

"ComeauTest .c", line 4: warning: exception specification for implicitly
declared
virtual function "cyclic_t::~cyc lic_t" is incompatible with
that of
overridden function "std::exception ::~exception"
class cyclic_t: public std::exception
^

GCC 3.2 issues an error

ConsoleTest.cpp :5: looser throw specifier for `virtual
cyclic_t::~cycl ic_t()'
/usr/include/c++/3.2/exception:54: overriding `virtual
std::exception: :~exception() throw ()'

Was something relevant to this issue changed in TC1?

--
Best regards,
Andrey Tarasevich