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;
}; 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
"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
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
"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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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
...
|
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....
|
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"...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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...
|
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)...
|
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
|
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...
| |