473,320 Members | 1,900 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

User-defined exceptions


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_param) {}
virtual const char *what() const throw() {return what_str.c_str();}

private:
std::string what_str;
};

Jul 22 '05 #1
5 6731
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_param) {}
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

Jul 22 '05 #2

"Andrey Tarasevich" <an**************@hotmail.com> wrote in message
news:vs************@news.supernews.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_param) {} 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
Jul 22 '05 #3
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_error'
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::unexpected' 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_error', 'std::range_error' 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

Jul 22 '05 #4

"Andrey Tarasevich" <an**************@hotmail.com> skrev i en meddelelse
news:vs************@news.supernews.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_param) {} 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
Jul 22 '05 #5
Peter Koch Larsen wrote:
"Andrey Tarasevich" <an**************@hotmail.com> skrev i en meddelelse
news:vs************@news.supernews.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_param) {} > 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::~cyclic_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::~cyclic_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

Jul 22 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

60
by: Fotios | last post by:
Hi guys, I have put together a flexible client-side user agent detector (written in js). I thought that some of you may find it useful. Code is here: http://fotios.cc/software/ua_detect.htm ...
3
by: zlst | last post by:
Many technological innovations rely upon User Interface Design to elevate their technical complexity to a usable product. Technology alone may not win user acceptance and subsequent marketability....
6
by: martin | last post by:
Hi, I am a web page and a web user control. My web user control is placed in my web page using the following directive <%@ Register TagPrefix="uc1" TagName="Header"...
1
by: Shourie | last post by:
I've noticed that none of the child controls events are firing for the first time from the dynamic user control. Here is the event cycle. 1) MainPage_load 2) User control1_Load user clicks a...
1
by: Robert Howells | last post by:
Perhaps I'm just too new at this to pull it off, or perhaps it's just bad architecture. I'd appreciate some feedback on the the wisdom (or lack thereof) in attempting the following: I'm not new...
7
by: jsale | last post by:
I'm currently using ASP.NET with VS2003 and SQL Server 2003. The ASP.NET app i have made is running on IIS v6 and consists of a number of pages that allow the user to read information from the...
0
by: tony | last post by:
Hello! This is a rather long mail but it's a very interesting one. I hope you read it. I have tried several times to get an answer to this mail but I have not get any answer saying something...
2
by: rn5a | last post by:
Assume that a user control (MyUC.ascx) encapsulates 2 TextBoxes with the IDs 'txt1' & 'txt2' respectively. To use this user control in an ASPX page, the following Register directive will be...
1
by: Carlettus | last post by:
Dear All, sorry but I'm not sure if this is the right place to post my problem. I was using the following asp code to create users in Active Directory. Suddenly, and I don't know the reason, users...
0
by: rbukkara | last post by:
Hi, I have got the following error while trying to add a user in the LDAP Directory. javax.naming.NameNotFoundException: ; remaining name 'uid=vassila,ou=People,dc=cs,dc=uno,dc=edu' I have...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.