sensing that an exception has occured

[Jacek Dziedzic]

Hi!

I'm trying to make friends with exceptions. I think I'm doing well,
there is
one thing that bothers me, however. If an object is declared within a try
block, it gets destroyed on exception, because then we're into the catch
block and out of the try block, right? How can I sense in the destructor
that we're in the middle of processing an exception (and hence take
appropriate action, like not destroying the object if some EInternalError
exception is being processed).

try {
myclass myinstance;
myinstance.DoSomethingThatCausesAnException();
}
catch(...) {
cout << "Exception" << endl;
};

myclass::~myclass() {
// take care of destroying the object, but not if we're in the middle
// of processing EInternalError, because the object is now corrupt.
// But how to find out?
};

TIA,
- J.

[Marko Becirevic]

> try {

myclass myinstance;
myinstance.DoSomethingThatCausesAnException();
}
catch(...) {
cout << "Exception" << endl;
};

myclass::~myclass() {
// take care of destroying the object, but not if we're in the middle
// of processing EInternalError, because the object is now corrupt.
// But how to find out?
};

One possible solution:

myinstance.SetFlag();
myinstance.DoSomethingThatCausesAnException();

myinstance.ResetFlag();

myclass::~myclass() {
if (!IsFlagSet()) {
...
}
};

[Nick Hounsome]

"Jacek Dziedzic" <jacek@__N_O_S_P_A_M__janowo.net> wrote in message
news:bu**********@korweta.task.gda.pl...

Hi!

I'm trying to make friends with exceptions. I think I'm doing well,
there is
one thing that bothers me, however. If an object is declared within a try
block, it gets destroyed on exception, because then we're into the catch
block and out of the try block, right? How can I sense in the destructor
that we're in the middle of processing an exception (and hence take
appropriate action, like not destroying the object if some EInternalError
exception is being processed).

try {
myclass myinstance;
myinstance.DoSomethingThatCausesAnException();
}
catch(...) {
cout << "Exception" << endl;
};

myclass::~myclass() {
// take care of destroying the object, but not if we're in the middle
// of processing EInternalError, because the object is now corrupt.
// But how to find out?
};

TIA,
- J.

If you really want to do this then have a flag (bool iscorrupt) in myclass,
set it before throwing the
exception and check it in the destructor.

Better still don't leave the object in a corrupt state.

[Janusz Szpilewski]

Jacek Dziedzic wrote:

Hi!

I'm trying to make friends with exceptions. I think I'm doing well,
there is
one thing that bothers me, however. If an object is declared within a try
block, it gets destroyed on exception, because then we're into the catch
block and out of the try block, right? How can I sense in the destructor
that we're in the middle of processing an exception (and hence take
appropriate action, like not destroying the object if some EInternalError
exception is being processed).

try {
myclass myinstance;
myinstance.DoSomethingThatCausesAnException();
}
catch(...) {
cout << "Exception" << endl;
};

myclass::~myclass() {
// take care of destroying the object, but not if we're in the middle
// of processing EInternalError, because the object is now corrupt.
// But how to find out?
};

You may add an extra member to myclass indicating whether the object of
that class is in consistent state and reset it anytime an exception is
being propagated through its member functions:

void myclass::DoSomethingThatCausesAnException()
{
try
{
// member function logic here
}
catch (...) // catch any exception leaving the function
{
m_isConsistent = false;
throw; // rethrows the exception
}
}

However it would be much better to handle such dangerous code as close
as possible where the problem still may be recoverable. So you should
put more exception checking inside of DoSomethingThatCausesAnException.
Leaving an uncleaned object is not a good idea.

Regards,
Janusz

[Howard]

"Jacek Dziedzic" <jacek@__N_O_S_P_A_M__janowo.net> wrote in message
news:bu**********@korweta.task.gda.pl...

Hi!

I'm trying to make friends with exceptions. I think I'm doing well,
there is
one thing that bothers me, however. If an object is declared within a try
block, it gets destroyed on exception, because then we're into the catch
block and out of the try block, right? How can I sense in the destructor
that we're in the middle of processing an exception (and hence take
appropriate action, like not destroying the object if some EInternalError
exception is being processed).

try {
myclass myinstance;
myinstance.DoSomethingThatCausesAnException();
}
catch(...) {
cout << "Exception" << endl;
};

myclass::~myclass() {
// take care of destroying the object, but not if we're in the middle
// of processing EInternalError, because the object is now corrupt.
// But how to find out?
};

I would not put an object declaration inside of a try block like that. Why
not put it before the try?

Better yet, I think the RAII method (resource acquisition is
initialization) might be designed just for this kind of an issue. It
involves making sure that construction of contained objects is handled in
such a way that 1) the constructor of the containing object is in a "clean
state" if construction of its sub-objects fails, and 2) the destruction of
the sub-objects will occur properly, regardless of whether that is taking
place in the context of an exception or not. (RAII is discussed in several
books, and you can do a Google search for more info, also.)

Perhaps if you posted the real code that you're having a problem with,
someone can suggest specific changes to redesign it to be exception safe.

-Howard

[Bob Bell]

"Jacek Dziedzic" <jacek@__N_O_S_P_A_M__janowo.net> wrote in message news:<bu**********@korweta.task.gda.pl>...

Hi!

I'm trying to make friends with exceptions. I think I'm doing well,
there is
one thing that bothers me, however. If an object is declared within a try
block, it gets destroyed on exception, because then we're into the catch
block and out of the try block, right? How can I sense in the destructor
that we're in the middle of processing an exception (and hence take
appropriate action, like not destroying the object if some EInternalError
exception is being processed).

try {
myclass myinstance;
myinstance.DoSomethingThatCausesAnException();
}
catch(...) {
cout << "Exception" << endl;
};

myclass::~myclass() {
// take care of destroying the object, but not if we're in the middle
// of processing EInternalError, because the object is now corrupt.
// But how to find out?
};

TIA,
- J.

Your object gets destroyed whether it's in the try block or not:

void F()
{
myclass x;
try {
x.DoSomethingThatCausesAnException();
}
catch (...) {
}
}

If your object is corrupted such that it can't be destroyed, you've
got a problem whether you're using exceptions or not.

void G()
{
myclass x;
x.DoSomethingThatCausesCorruption();
}

By "corrupted" I mean your object has gotten into a state that you
didn't anticipate or account for -- in other words, you've got a bug.
You need to fix the bug, not throw an exception. If this isn't what
you mean by corruption, then you don't really have a problem -- the
object should satisfy its invariants and should be destructible.
Meaning that myclass::DoAnything() should leave the object
destructible regardless of whether it returns normally or throws an
exception.

Bugs occur when your program behaves incorrectly; the proper response
is to fix the bug. Exceptions, on the other hand, are all about
letting your program continue execution; when an exception is thrown
in both your example and mine, the program will go on executing -- the
object gets destroyed, the function returns, etc.

To answer your question, there is a function called
std::uncaught_exception() which returns true between the time when an
exception is thrown and when it is caught. However, it's not as useful
as you might think. For example, it won't solve the problem you've
described, because the problem you've described is a bug, and calling
std::uncaught_exception() won't fix the bug.

Not to mention that I'm unaware of any compiler that actually
implements std::uncaught_exception()...

Note that if you call std::uncaught_exception() in the destructor in
your example, it will return true; in my example it would return
false.

Bob

[Jacek Dziedzic]

"Bob Bell" <be****@pacbell.net> wrote in message
news:c8**************************@posting.google.c om...

First of all, I'd like to thank a lot for all the responses!

[...]
Your object gets destroyed whether it's in the try block or not:

Actually, if I move it out of the try block it does not get destroyed,
because the catch(...) block, if EInternalError is caught, displays a
message and calls abort() which (I think) doesn't give the object a
chance to get destroyed.
If your object is corrupted such that it can't be destroyed, you've
got a problem whether you're using exceptions or not.

Yes, of course. I'm throwing these EInternalError exceptions in
places when I would normally use assert()'s -- I don't expect the
program to do anything meanigful under these circumstances -- printing
a "fatal error" message and terminating uncleanly is enough, as these
should only occur in developed code and indicate serious bugs in code.
The problem was, that whenever this exception occured, *before*
getting to the catch(...) block that used to abort() the program, the
destructor was called, and since my objects were quite complex it
was almost certain the destructor would blow when the object was
corrupt, hence either throwing EInternalError again or, worse, segfaulting
or going into undefined behaviour.
To answer your question, there is a function called
std::uncaught_exception() which returns true between the time when an
exception is thrown and when it is caught. However, it's not as useful
as you might think. For example, it won't solve the problem you've
described, because the problem you've described is a bug, and calling
std::uncaught_exception() won't fix the bug.
That would satisfy me.
Not to mention that I'm unaware of any compiler that actually
implements std::uncaught_exception()...

Or perhaps not :).

thanks a lot, I guess I'll stick with a
"major_problems_dont_perform_destructor"
flag.
- J.

[Bob Bell]

"Jacek Dziedzic" <jacek@__N_O_S_P_A_M__janowo.net> wrote in message news:<bu**********@korweta.task.gda.pl>...

"Bob Bell" <be****@pacbell.net> wrote in message
news:c8**************************@posting.google.c om...

First of all, I'd like to thank a lot for all the responses!

[...]
Your object gets destroyed whether it's in the try block or not:

Actually, if I move it out of the try block it does not get destroyed,
because the catch(...) block, if EInternalError is caught, displays a
message and calls abort() which (I think) doesn't give the object a
chance to get destroyed.

umm...

If your object is corrupted such that it can't be destroyed, you've
got a problem whether you're using exceptions or not.

Yes, of course. I'm throwing these EInternalError exceptions in
places when I would normally use assert()'s -- I don't expect the
program to do anything meanigful under these circumstances -- printing
a "fatal error" message and terminating uncleanly is enough, as these
should only occur in developed code and indicate serious bugs in code.

Then use assert. What do you gain by throwing, besides the problem
you've described?

As I said, exceptions are all about keeping the program running. If
what you want to do is shut down the program, shut it down. Don't
throw.

Bob