«

Hello

I want to understand the exception habdling in C++ more, because i
think no one can apply anything free (free - without remembering large
unclear list of rules and exceptions from rules and exceptions from
exception from rules) if he does not understand "why" the thing have
done excactly as is.

I know, some people do not agree with me at the point of "why".

1.
I think, the exception is statical linknig, in other words, each throw
"knows" it appropriate catch during comile time.

Is it true?

I think it is true, due to exit() called, if no external try{} block
exist (no "stack unwinding" has occured).

What exactly happends while exceptions? In asm list i can see something
like this:

call function

normal return point:
clear stack if needed
uncondition jmp to exit

return from exception point:
clear stack if needed
push retruned value
call ___cxa_begin_catch

exit:

2.
The question is next:

I have destructor, which can be executed after exception have thrown,
during "stack unwinding". My destructor can create temporary objects,
and each of the created object can throw, in general.

If i throw while i have std::uncaught_exception()!=0, the exit() (oh,
mamma mia will be called.

But if i declare new try{} block inside destructor, can temporary
objects safe throw or can not and why?

~Base()
{
try{
A a;
B b;
Base::free(a,b);
}catch(...){ if( !std::uncaught_exception() ) throw; }
}

Why?

Thanks.

Tell me anything

On Jan 14, 3:12 pm, "Grizlyk" <grizl...@yandex.ru> wrote:
> Hello
>
> I want to understand the exception habdling in C++ more, because i
> think no one can apply anything free (free - without remembering large
> unclear list of rules and exceptions from rules and exceptions from
> exception from rules) if he does not understand "why" the thing have
> done excactly as is.
>
> I know, some people do not agree with me at the point of "why".
>
> 1.
> I think, the exception is statical linknig, in other words, each throw
> "knows" it appropriate catch during comile time.
>
> Is it true?

Sounds logical to me, but remember that you should never concern
yourself with how it's done on _your_ machine, but rather how it's done
according to the standard. Different vendors might do it in different
ways, and different versions of the same compiler (or just changing
some settings) can do it in different ways. So what you should
concentrate on is what it means from the point of view of your C++
application, everything else can change.

--
Erik Wikström

Grizlyk skrev:
> Hello
>
> I want to understand the exception habdling in C++ more, because i
> think no one can apply anything free (free - without remembering large
> unclear list of rules and exceptions from rules and exceptions from
> exception from rules) if he does not understand "why" the thing have
> done excactly as is.

Stan Lippman wrote a book about "C++ internals" - that is how you might
implement stuff such as exceptions, virtual functions, constructors and
so on. It is old, and I haven't read it myself but I did have a few
hours of skimming, and what I saw looked real nice. You have to google
for the title, however.
You could also read the standard committees report on C++ performance.
It has a very good chapter on exceptions and is available online. Again
you'll have to google.
>
> I know, some people do not agree with me at the point of "why".
>
> 1.
> I think, the exception is statical linknig, in other words, each throw
> "knows" it appropriate catch during comile time.
>
> Is it true?

No.

>
> I think it is true, due to exit() called, if no external try{} block
> exist (no "stack unwinding" has occured).
>
> What exactly happends while exceptions? In asm list i can see something
> like this:
>
> call function
>
> normal return point:
> clear stack if needed
> uncondition jmp to exit
>
> return from exception point:
> clear stack if needed
> push retruned value
> call ___cxa_begin_catch
>
> exit:
>
> 2.
> The question is next:
>
> I have destructor, which can be executed after exception have thrown,
> during "stack unwinding". My destructor can create temporary objects,
> and each of the created object can throw, in general.
>
> If i throw while i have std::uncaught_exception()!=0, the exit() (oh,
> mamma mia will be called.
>
> But if i declare new try{} block inside destructor, can temporary
> objects safe throw or can not and why?

A temporary object can throw, of course.

>
> ~Base()
> {
> try{
> A a;
> B b;
> Base::free(a,b);
> }catch(...){ if( !std::uncaught_exception() ) throw; }
> }

This looks fine, but beware that not all compilers support
std::uncaught_exception(). Also, it is problematic that destructors
should need to throw. In my opinion, they should normally not throw,
and doing so could be an indication that you have a problem with your
class.
>
> Why?


/Peter

* Erik Wikström:
> On Jan 14, 3:12 pm, "Grizlyk" <grizl...@yandex.ru> wrote:
>> Hello
>>
>> I want to understand the exception habdling in C++ more, because i
>> think no one can apply anything free (free - without remembering large
>> unclear list of rules and exceptions from rules and exceptions from
>> exception from rules) if he does not understand "why" the thing have
>> done excactly as is.
>>
>> I know, some people do not agree with me at the point of "why".
>>
>> 1.
>> I think, the exception is statical linknig, in other words, each throw
>> "knows" it appropriate catch during comile time.
>>
>> Is it true?
>
> Sounds logical to me

Consider:

#include <iostream>
#include <ostream>
#include <stdexcept>

void foo()
{
throw std::runtime_error( "Boo!" ); // Which catch?
}

void say( char const s[] ){ std::cout << s << std::endl; }

void a() { try{ foo(); }catch{...}{ say( "Argh!" ); } }
void b() { try( foo(); }catch{...}{ say( "Brgh!" ); } }

int main() { a(); b(); }

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Grizlyk" <> wrote in message
news: oups.com...
>
> 1.
> I think, the exception is statical linknig, in other words, each throw
> "knows" it appropriate catch during comile time.

Here's but just one way to implement exceptions:

Every catch-block generates an entry in one or more tables
that the compiler maintains internally. There is one table for
every type being caught anywhere, and the table contains
pointers to all such catch-blocks (perhaps coming from many
compiled object files, or even library).

When an object of some type is being thrown, the compiler
generates (or _statically_ links from run-time library!) code to
scan the table of catch-blocks for that type. The same code
also scans the stack, and for each stack frame, it either finds
a catch-block from the table (to which it then jumps), or if it
does not find one, it unwinds the current stack frame and
proceeds to the next one.

- Risto -

peter koch wrote:

> > But if i declare new try{} block inside destructor, can temporary
> > objects safe throw or can not and why?
>
> A temporary object can throw, of course.

Does standard allow creation new try block during
"std::uncaught_exception()"?

Grizlyk skrev:
> peter koch wrote:
>
> > > But if i declare new try{} block inside destructor, can temporary
> > > objects safe throw or can not and why?
> >
> > A temporary object can throw, of course.
>
> Does standard allow creation new try block during
> "std::uncaught_exception()"?
Yes

Risto Lankinen wrote:
>
> Every catch-block generates an entry in one or more tables
> that the compiler maintains internally. There is one table for
> every type being caught anywhere, and the table contains
> pointers to all such catch-blocks (perhaps coming from many
> compiled object files, or even library).
>
> When an object of some type is being thrown, the compiler
> generates (or _statically_ links from run-time library!) code to
> scan the table of catch-blocks for that type. The same code
> also scans the stack, and for each stack frame, it either finds
> a catch-block from the table (to which it then jumps), or if it
> does not find one, it unwinds the current stack frame and
> proceeds to the next one.
>

> the compiler generates code
> (or _statically_ links from run-time library!)

Yes, can not be constant statical link, becasue function can be
declared in one module, but try block in another.

All other not clear.
Where can I read in inet more detailed description with screenshot of
stack's state at each step of execution of symple code example (for any
exception implementation)?