Exceptions creating Exceptional Problems!

[makuchaku]

Hi all

I'm facing a strange problem in C++ exceptions.

If an error occurs in a class, throw() is used. But whenever that
happens, the object is destroyed.

In a nutshell, accessing the object in which exception occured is not
being possible in catch block.

Either i'm interpreting the things wrongly, or is it a limitation...

Please suggest some workaround AND|OR clear my mis-interpretation.

A more detailed version of my question can be found at my blog...
http://makuchaku.blogspot.com/2005/0...ceptional.html
Do reply asap...

Thanks,
makuchaku

[Ivan Vecerina]

"makuchaku" <ma********@gmail.com> wrote in message
news:11*********************@c13g2000cwb.googlegro ups.com...

I'm facing a strange problem in C++ exceptions.

If an error occurs in a class, throw() is used. But whenever that
happens, the object is destroyed.

In a nutshell, accessing the object in which exception occured is not
being possible in catch block.

Either i'm interpreting the things wrongly, or is it a limitation...

Please suggest some workaround AND|OR clear my mis-interpretation.

A more detailed version of my question can be found at my blog...
http://makuchaku.blogspot.com/2005/0...ceptional.html
Do reply asap... The code was short enough that you could have posted it here:
#include<...>
void main()
{
try
{
Socket object(); The above is a function declaration. I guess you meant:
Socket object; object.do_something_else();
}catch(SockException err)
{
err.getCode(); //works
err.getMessage(); //works
//object.cannot_access_this(); <----- this is troublesome! For that to work, 'object' need to be declared outside of/prior to
the try block:
Socket object;
try {
..... }
}

Of course this implies that if you cannot access the object in a
catch clasue if its constructor has thrown an exception. If the
constructor did not execute successfully, there is no object to
be accessed.

Eventually, you may want to use two-step initialization: a
non-throwing constructor that creates an instance in a fail-safe
state, and a separate function to attempt the creation of a
resource (or connection, in this instance).

This very much makes sense to me.
Do you consider this to be a practical problem ?

Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[makuchaku]

your idea can be a possible solution.
I also found another way!
int main()
{
Socket *s;
try
{
s = new Socket(ERRORNEOUS_VALUE);
}catch(...)
{
s->memberFunction();
}
}

atleast this works. Now its upto me, how do i design my class.
anyways, thanks for your help.

makuchaku

[Ivan Vecerina]

"makuchaku" <ma********@gmail.com> wrote in message
news:11*********************@c13g2000cwb.googlegro ups.com...

your idea can be a possible solution.
I also found another way!

int main()
{
Socket *s;
try
{
s = new Socket(ERRORNEOUS_VALUE);
}catch(...)
{
s->memberFunction();
}
}
atleast this works. Now its upto me, how do i design my class.

Here you have traded a compile-time error for Undefined Behavior!
If the above code works, it is by accident - and it will fail
(or erase your HD etc) with a different compiler setting or some
other change of circumstances.
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[makuchaku]

hi,
you may be correct, but what if i'm in a parent>child>sub-child
environment & want that after error in sub-child class, the child class
should not die/end.

makuchaku

[velthuijsen]

makuchaku wrote:

hi,
you may be correct, but what if i'm in a parent>child>sub-child
environment & want that after error in sub-child class, the child class should not die/end.

makuchaku

Then you should do as I. Vecerina suggested. (Re)build the constructor
of Socket so that it will not throw (user defined exceptions that is)
and write an initializer function that is allowed to throw.