473,241 Members | 1,448 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,241 software developers and data experts.

sensing that an exception has occured

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.
Jul 22 '05 #1
7 1865
> 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()) {
...
}
};
Jul 22 '05 #2

"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.
Jul 22 '05 #3
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

Jul 22 '05 #4

"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



Jul 22 '05 #5
"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
Jul 22 '05 #6
"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.
Jul 22 '05 #7
"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
Jul 22 '05 #8

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

Similar topics

5
by: Jacek Dziedzic | last post by:
Hi! In my main() function I have a last-resort exception construct that looks like this: int main() { try { // ... program code }
3
by: David | last post by:
Hi, Ive been trying to work this out for the past 2 days now and im not getting anywhere fast. The problem i have is that i am using Asynchronous sockets to create a Socket Client library....
6
by: Vadivel Kumar | last post by:
I've a problem in handling a custom exception The following is my custom exception class: public class AppException : public Exception { public AppException (string message, Exception...
3
by: bobueland | last post by:
Sometimes the best way to understand something is to understand the mechanism behind it. Maybe that is true for exceptions. This is a model I have right now (which probably is wrong) 1. When a...
132
by: Zorro | last post by:
The simplicity of stack unraveling of C++ is not without defective consequences. The following article points to C++ examples showing the defects. An engineer aware of defects can avoid...
9
by: Frawls | last post by:
Hi I Am am having problems with a stored Procedure that i wrote. Basically whats happening is that the Stored procedure Runs fine when i EXECUTE it in SQL Query analyzer. But when i debug...
4
by: leelaprasad.gorrepati | last post by:
We had written an application in which we create worker thread. So the main thread will create the worker thread. After some time the child thread(Worker thread) will call pthread_exit(). This...
1
by: platso | last post by:
We had written an application in which we create worker thread. So the main thread will create the worker thread. After some time the child thread(Worker thread) will call pthread_exit()....
0
by: srizzler | last post by:
Hi All: I am trying to implement Exception Handling using Enterprise Library 3.1's Exception Handling Application Block as well as Logging Blocks. I have a windows application developed in...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
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: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
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...

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.