Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Can I tell in the destructor if an exception occured ?

Reply
Thread Tools

Can I tell in the destructor if an exception occured ?

 
 
Timothy Madden
Guest
Posts: n/a
 
      11-17-2004
Hy

I have destructors that do some functional work in the program flow.
The problem is destructors should only be used for clean-up, because
exceptions might rise at any time, and destructors will be called for
clean-up only.

So how can I tell, from within the destructor, if the call has been made as
part of normal flow of control and the destructor can play its functional
role, or if the call has been made as a result of an exception and the
destructor should rollback, abort and clean up ?

What if I need to propagate this state to other destructors that are called
before the current destructor returns, so that the other destructors can
take appropiate action ?

How come there is no real way to comunicate with the destructors ?
Constructors I can choose, I can pass parameters to, but for destructors ?

Thank you
"Timothy Madden"
Romania


 
Reply With Quote
 
 
 
 
Bob Hairgrove
Guest
Posts: n/a
 
      11-17-2004
On Wed, 17 Nov 2004 12:47:27 +0200, "Timothy Madden"
<(E-Mail Removed)> wrote:

>Hy
>
>I have destructors that do some functional work in the program flow.
>The problem is destructors should only be used for clean-up, because
>exceptions might rise at any time, and destructors will be called for
>clean-up only.
>
>So how can I tell, from within the destructor, if the call has been made as
>part of normal flow of control and the destructor can play its functional
>role, or if the call has been made as a result of an exception and the
>destructor should rollback, abort and clean up ?
>
>What if I need to propagate this state to other destructors that are called
>before the current destructor returns, so that the other destructors can
>take appropiate action ?
>
>How come there is no real way to comunicate with the destructors ?
>Constructors I can choose, I can pass parameters to, but for destructors ?
>
>Thank you
>"Timothy Madden"
>Romania
>


uncaught_exception() will tell you. But many compilers apparently have
had trouble with it until only recently, e.g. GCC 3.4 was reported to
handle it OK, whereas earlier versions did not.

--
Bob Hairgrove
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Timothy Madden
Guest
Posts: n/a
 
      11-17-2004

"Bob Hairgrove" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Wed, 17 Nov 2004 12:47:27 +0200, "Timothy Madden"
> <(E-Mail Removed)> wrote:
>
> >Hy
> >
> >I have destructors that do some functional work in the program flow.
> >The problem is destructors should only be used for clean-up, because
> >exceptions might rise at any time, and destructors will be called for
> >clean-up only.
> >
> >So how can I tell, from within the destructor, if the call has been made

as
> >part of normal flow of control and the destructor can play its functional
> >role, or if the call has been made as a result of an exception and the
> >destructor should rollback, abort and clean up ?
> >
> >What if I need to propagate this state to other destructors that are

called
> >before the current destructor returns, so that the other destructors can
> >take appropiate action ?
> >
> >How come there is no real way to comunicate with the destructors ?
> >Constructors I can choose, I can pass parameters to, but for destructors

?
> >
> >Thank you
> >"Timothy Madden"
> >Romania
> >

>
> uncaught_exception() will tell you. But many compilers apparently have
> had trouble with it until only recently, e.g. GCC 3.4 was reported to
> handle it OK, whereas earlier versions did not.
>

I tryed it on my platform (80x86, Win2000, VC++ 6.0 SP5), it doesn't work

Anything else I can do ?
Anything ?

Thank you
"Timothy Madden"
Romania


 
Reply With Quote
 
Bob Hairgrove
Guest
Posts: n/a
 
      11-17-2004
On Wed, 17 Nov 2004 14:02:21 +0200, "Timothy Madden"
<(E-Mail Removed)> wrote:

>> uncaught_exception() will tell you. But many compilers apparently have
>> had trouble with it until only recently, e.g. GCC 3.4 was reported to
>> handle it OK, whereas earlier versions did not.
>>

> I tryed it on my platform (80x86, Win2000, VC++ 6.0 SP5), it doesn't work
>
> Anything else I can do ?


Yes. Update your compiler to MSVC++ 7.1 ... quickly. Version 6 is
broken in many ways. BTW you can download the command-line version for
free from the MS website, called "MS Visual C++ Toolkit". The drawback
is that they only provide static libraries to link with the C/C++
runtime libraries. But otherwise, it is fully functional and you can
use code optimizations.

Unfortunately, I have never had occasion to use uncaught_exception
myself yet, so I cannot say whether it works with this compiler or
not.

--
Bob Hairgrove
(E-Mail Removed)
 
Reply With Quote
 
slurper
Guest
Posts: n/a
 
      11-17-2004
Timothy Madden wrote:

> Hy
>
> I have destructors that do some functional work in the program flow.
> The problem is destructors should only be used for clean-up, because
> exceptions might rise at any time, and destructors will be called for
> clean-up only.


seems to me like a strange design
why not do the functional work out of the destructor?
as you say, destructors should be called for cleanup (e.g. cleaning up a
socket, call other object's destructor, ...) , not for common logic in your
program. you can put the logic before you're object is going out of scope
(and the destructor will be called) (or before a manual call to the
destructor)

>
> So how can I tell, from within the destructor, if the call has been made
> as part of normal flow of control and the destructor can play its
> functional role, or if the call has been made as a result of an exception
> and the destructor should rollback, abort and clean up ?
>
> What if I need to propagate this state to other destructors that are
> called before the current destructor returns, so that the other
> destructors can take appropiate action ?


a destructor should clean-up resources that this object hold. that's the
only purpose. if this object is destroyed, ask yourself which other objects
need to be destroyed.
if an error occurs, you can catch the exception and do whatever needs to be
done in the exception handler (possibly destroying resources). if no error
occurs, just do what you mean to do according to normal flow of execution.
remember that the destructor should never contain "normal program
flow"-code.
>
> How come there is no real way to comunicate with the destructors ?
> Constructors I can choose, I can pass parameters to, but for destructors ?
>
> Thank you
> "Timothy Madden"
> Romania


 
Reply With Quote
 
Timothy Madden
Guest
Posts: n/a
 
      11-17-2004

"slurper" <(E-Mail Removed)> wrote in message
news:419b5790$0$13457$(E-Mail Removed)...
> Timothy Madden wrote:
>
> > Hy
> >
> > I have destructors that do some functional work in the program flow.
> > The problem is destructors should only be used for clean-up, because
> > exceptions might rise at any time, and destructors will be called for
> > clean-up only.

>
> seems to me like a strange design
> why not do the functional work out of the destructor?
> as you say, destructors should be called for cleanup (e.g. cleaning up a
> socket, call other object's destructor, ...) , not for common logic in

your
> program. you can put the logic before you're object is going out of scope
> (and the destructor will be called) (or before a manual call to the
> destructor)
>

Yes it is, I have no better ideea. However if anyone knows please tell me
what could be the solution.

I wrote a class used to fill in records in tables from a relational
database.
Records in a related table should be updated and commited in the database
only after the coresponding record in the master table, to respect
referential integrity. The purpose of the class is to allow the application
to fill the tables in whatever order it wishes, provided that when everey
record is done, overall referential integrity is respected.

The strategy is to buffer update requests on the related table until the
master table is updated, when the related updates are also flushed/commited.

The objects of the class just fill in filelds in the record. The update
happens automaticaly in the destructor, if if is possible, followed by
updates of related records. If it is not possible (the master table is not
ready yet) then the destructor buffers the update command and lets the
destructor of the master table do the job when it gets called.

Someone has a better way to do this without destructors ?

Thank you
"Timothy Madden"
Romania


 
Reply With Quote
 
slurper
Guest
Posts: n/a
 
      11-17-2004
Timothy Madden wrote:

>
> "slurper" <(E-Mail Removed)> wrote in message
> news:419b5790$0$13457$(E-Mail Removed)...
>> Timothy Madden wrote:
>>
>> > Hy
>> >
>> > I have destructors that do some functional work in the program flow.
>> > The problem is destructors should only be used for clean-up, because
>> > exceptions might rise at any time, and destructors will be called for
>> > clean-up only.

>>
>> seems to me like a strange design
>> why not do the functional work out of the destructor?
>> as you say, destructors should be called for cleanup (e.g. cleaning up a
>> socket, call other object's destructor, ...) , not for common logic in

> your
>> program. you can put the logic before you're object is going out of scope
>> (and the destructor will be called) (or before a manual call to the
>> destructor)
>>

> Yes it is, I have no better ideea. However if anyone knows please tell me
> what could be the solution.
>
> I wrote a class used to fill in records in tables from a relational
> database.
> Records in a related table should be updated and commited in the database
> only after the coresponding record in the master table, to respect
> referential integrity. The purpose of the class is to allow the
> application to fill the tables in whatever order it wishes, provided that
> when everey record is done, overall referential integrity is respected.
>
> The strategy is to buffer update requests on the related table until the
> master table is updated, when the related updates are also
> flushed/commited.
>
> The objects of the class just fill in filelds in the record. The update
> happens automaticaly in the destructor, if if is possible, followed by
> updates of related records. If it is not possible (the master table is not
> ready yet) then the destructor buffers the update command and lets the
> destructor of the master table do the job when it gets called.
>
> Someone has a better way to do this without destructors ?


if i understand well: why not first write the logic to update the master
table and then write the logic to update the table which references the
master table? (in a sequential manner) you can combine both operations on
the database in a transaction if your database management system supports
it (but that's not necessary per se). why do you want to put that in a
destructor?

>
> Thank you
> "Timothy Madden"
> Romania


 
Reply With Quote
 
Bob Hairgrove
Guest
Posts: n/a
 
      11-17-2004
On Wed, 17 Nov 2004 16:37:57 +0200, "Timothy Madden"
<(E-Mail Removed)> wrote:

>I wrote a class used to fill in records in tables from a relational
>database.
>Records in a related table should be updated and commited in the database
>only after the coresponding record in the master table, to respect
>referential integrity. The purpose of the class is to allow the application
>to fill the tables in whatever order it wishes, provided that when everey
>record is done, overall referential integrity is respected.
>
>The strategy is to buffer update requests on the related table until the
>master table is updated, when the related updates are also flushed/commited.
>
>The objects of the class just fill in filelds in the record. The update
>happens automaticaly in the destructor, if if is possible, followed by
>updates of related records. If it is not possible (the master table is not
>ready yet) then the destructor buffers the update command and lets the
>destructor of the master table do the job when it gets called.
>
>Someone has a better way to do this without destructors ?


Perhaps. It would depend on the RDBMS you have.

In general, such multi-table updates are best wrapped in a transaction
which can be committed or rolled back as a whole. If you indeed have a
referential DBMS, then you should have foreign key constraints in
place, otherwise it is very dangerous to do what you are trying to do
(i.e. enforce referential integrity in the application instead of in
the database) because of the danger of inconsistent data when
something goes wrong.

--
Bob Hairgrove
(E-Mail Removed)
 
Reply With Quote
 
puppet_sock@hotmail.com
Guest
Posts: n/a
 
      11-17-2004
"Timothy Madden" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> I have destructors that do some functional work in the program flow.
> The problem is destructors should only be used for clean-up, because
> exceptions might rise at any time, and destructors will be called for
> clean-up only.


Um. Not sure I'm following what you mean. Can you give some more
description of what you mean by "functional work in the program
flow?" Because destructors *should* only get called for cleanup.
(And resource deallocation, and such like.) So, I'm thinking
you've done something pretty strange.
Socks
 
Reply With Quote
 
Timothy Madden
Guest
Posts: n/a
 
      11-18-2004

"Bob Hairgrove" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Wed, 17 Nov 2004 16:37:57 +0200, "Timothy Madden"
> <(E-Mail Removed)> wrote:
>
> >I wrote a class used to fill in records in tables from a relational
> >database.
> >Records in a related table should be updated and commited in the database
> >only after the coresponding record in the master table, to respect
> >referential integrity. The purpose of the class is to allow the

application
> >to fill the tables in whatever order it wishes, provided that when everey
> >record is done, overall referential integrity is respected.
> >
> >The strategy is to buffer update requests on the related table until the
> >master table is updated, when the related updates are also

flushed/commited.
> >
> >The objects of the class just fill in filelds in the record. The update
> >happens automaticaly in the destructor, if if is possible, followed by
> >updates of related records. If it is not possible (the master table is

not
> >ready yet) then the destructor buffers the update command and lets the
> >destructor of the master table do the job when it gets called.
> >
> >Someone has a better way to do this without destructors ?

>
> Perhaps. It would depend on the RDBMS you have.
>
> In general, such multi-table updates are best wrapped in a transaction
> which can be committed or rolled back as a whole. If you indeed have a
> referential DBMS, then you should have foreign key constraints in
> place, otherwise it is very dangerous to do what you are trying to do
> (i.e. enforce referential integrity in the application instead of in
> the database) because of the danger of inconsistent data when
> something goes wrong.
>

I can't say what RDBMS I have because I do not relay on one of them.
I can change the DBMS as this choice does not affect the application and I
currently am not satisfied with the one I use (Access 2000).
Transaction support is a property of the DBMS so there isn't much I can do
about it in the application. I have set foreign key constraints in the
database
and I try to follow them in the app (not enforce them); this is way I've
done
my class.

Thank you
"Timothy Madden"
Romania


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unknown exception occured for pthread_exit() leelaprasad.gorrepati@gmail.com C++ 4 11-29-2007 11:02 AM
An Exception 'System.StackOverflowException' has occured in /LM/W3SVC/1/Root/... HyVong ASP .Net 1 11-25-2005 01:47 AM
WinDBG bug? Single step exception occured. =?Utf-8?B?SG9vbg==?= Windows 64bit 0 10-07-2005 04:48 AM
sensing that an exception has occured Jacek Dziedzic C++ 8 01-18-2004 05:27 AM
exception OE has occured Shamah Computer Support 4 11-06-2003 12:24 PM



Advertisments