Throwing Errors

[Ruben]

Hello

I'm struggling with the throw and catch exception system. As I understood
it, when you throw an error, that the stack is searched for a matching
catch, but I'm having difficult finding where to put a catch that can be
found by all the methods in a class. Can't I include a try{}catch in a
constructor and then expect it to be found by throws which are littered
throughout my object?

Also, if I have an class object within my class in a hasa relationship,
can the included object reach throw things to the enclosed object, or is
that another space altogether unless real inheritance is used?

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Andrey Tarasevich]

Ruben wrote:

I'm struggling with the throw and catch exception system. As I understood
it, when you throw an error, that the stack is searched for a matching
catch, but I'm having difficult finding where to put a catch that can be
found by all the methods in a class.

There's no way to create a 'catch' that will catch exceptions thrown "by
all the methods in a class". The search for the matching handler is not
in any way tied to the type definitions or their relationships.

The term "stack" (the one that's searched for the handler) refers to the
run-time execution stack the way it looked at the moment when the
exception was thrown, i.e. "stack" is the sequence of nested function
contexts leading from 'main' to the 'throw' in question.

Can't I include a try{}catch in a
constructor and then expect it to be found by throws which are littered
throughout my object?

No, that's completely unrelated.

Also, if I have an class object within my class in a hasa relationship,
can the included object reach throw things to the enclosed object, or is
that another space altogether unless real inheritance is used?

Same thing. The search for the matching handler is not in any way tied
to the data structures. It has nothing to do with inheritance or any
other relationships, like 'has-a'. As stated above, it is defined by the
run-time sequence of function call contexts.

--
Best regards,
Andrey Tarasevich

[Ruben]

On Tue, 16 Sep 2008 12:50:26 -0700, Andrey Tarasevich wrote:

The term "stack" (the one that's searched for the handler) refers to the
run-time execution stack the way it looked at the moment when the
exception was thrown, i.e. "stack" is the sequence of nested function
contexts leading from 'main' to the 'throw' in question.

Well that is where I'm confused. Why isn't the constructor in the stack
of the object.

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ruben]

On Tue, 16 Sep 2008 12:50:26 -0700, Andrey Tarasevich wrote:

>
Same thing. The search for the matching handler is not in any way tied to
the data structures. It has nothing to do with inheritance or any other
relationships, like 'has-a'. As stated above, it is defined by the
run-time sequence of function call contexts.

but if one object is calling anoother object why is it not in the stack

main calls a construstor which instantates an object which calls another
constructor which instantates another object which causes an error.

Ruben
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Kai-Uwe Bux]

Ruben wrote:

On Tue, 16 Sep 2008 12:50:26 -0700, Andrey Tarasevich wrote:

>The term "stack" (the one that's searched for the handler) refers to the
run-time execution stack the way it looked at the moment when the
exception was thrown, i.e. "stack" is the sequence of nested function
contexts leading from 'main' to the 'throw' in question.

Well that is where I'm confused. Why isn't the constructor in the stack
of the object.

a) There is no "stack of the object".

b) The constructors local storage is part of stack while the constructor is
running. Once it is done, the object is constructed and the constructors
local storage is removed from the stack. Exceptions thrown at that point
cannot be caught by a try-catch block in the constructor since the
constructor is no longer part of the stack.
Best

Kai-Uwe Bux

[Ruben]

On Tue, 16 Sep 2008 19:59:19 -0400, Kai-Uwe Bux wrote:

Exceptions thrown at
that point cannot be caught by a try-catch block in the constructor since
the constructor is no longer part of the stack.

Yes - I can see that. It makes it seem that throw, try and catch are
very limited tools and I just don't see how it improves error handling.

Other than wrapping main into a try block, it seems hard to get anything
useful out of it in terms of organizing exception handling.
Any even still, an class object called from and in a has relationship
with a class oject I would think would still be in the stack of the
claling object.

Ruben
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Andrey Tarasevich]

Ruben wrote:

> Exceptions thrown at
that point cannot be caught by a try-catch block in the constructor since
the constructor is no longer part of the stack.

Yes - I can see that. It makes it seem that throw, try and catch are
very limited tools and I just don't see how it improves error handling.

No, they are not very limited and they do improve error handling.

Other than wrapping main into a try block, it seems hard to get anything
useful out of it in terms of organizing exception handling.

Most likely because you are trying to think about C++ program in terms
of some alternative data/execution model, which in fact has no relevance
to C++ at all. It might be an interesting exercise, but with very little
immediate practical value.

Any even still, an class object called from and in a has relationship
with a class oject I would think would still be in the stack of the
claling object.

There's no such thing as "an object calling another object" in C++.
Objects are data. Data cannot "call" anything and cannot be "called"
from anywhere. The only things that can be called are _functions_. It
could be either standalone functions, or member functions - doesn't
matter. But it is still about functions, not objects. The program
execution flow in C++ is a sequence of [possibly nested] function calls.
This flow is what you can wrap into exception handlers. Data structures,
objects and their relationships are beside the point.

--
Best regards,
Andrey Tarasevich

[Kai-Uwe Bux]

Ruben wrote:

On Tue, 16 Sep 2008 19:59:19 -0400, Kai-Uwe Bux wrote:

> Exceptions thrown at
that point cannot be caught by a try-catch block in the constructor since
the constructor is no longer part of the stack.

Yes - I can see that. It makes it seem that throw, try and catch are
very limited tools and I just don't see how it improves error handling.

Other than wrapping main into a try block, it seems hard to get anything
useful out of it in terms of organizing exception handling.
Any even still, an class object called from and in a has relationship
with a class oject I would think would still be in the stack of the
claling object.

You missed something: there is no "stack of the (calling) object".

Also, in C++ object do not call one another. The relation

__ calls __

is a relation between methods/functions, not a relation between objects.

Best

Kai-Uwe Bux

[Fred Zwarts]

"Ruben" <ru***@www2.mrbrklyn.comwrote in message news:pa****************************@www2.mrbrklyn. com...

On Tue, 16 Sep 2008 12:50:26 -0700, Andrey Tarasevich wrote:

>
Same thing. The search for the matching handler is not in any way tied to
the data structures. It has nothing to do with inheritance or any other
relationships, like 'has-a'. As stated above, it is defined by the
run-time sequence of function call contexts.

but if one object is calling anoother object why is it not in the stack

An object does not call. An object cannot be called.

main calls a construstor which instantates an object which calls another
constructor which instantates another object which causes an error.

The constructor is a function. One function can call another function.
A constructor can call another constructor. In that case the first
constructor can "catch" exceptions "thrown" by the second constructor.
E.g.:

class FirstClass {
AnotherClass AnotherObject;
FirstClass (); // Constructor
};

FirstClass::FirstClass () try
: AnotherObject () // Call construcor of another class
{
} catch (...) {
// Handle exceptions in the construction of AnotherObject.
}
}