Stack unwinding: can I avoid it?

[Tony]

Well the subject says it all. Do I have to have it if I use classes in C++?

Tony

 

[Greg]

Well the subject says it all. Do I have to have it if I use classes in C++?

A C++ program can use setjmp/longjmp to transfer execution to an
enclosing scope without "unwinding" the stack (that is, invoking the
destructors of objects with lifetimes bound to an intervening scope).
But I cannot think of a good reason why a C++ program would resort to
this technique, so I suspect there is a better question that could
asked instead of this one.

Greg

 

[Markus Moll]

Well the subject says it all. Do I have to have it if I use classes in
C++?

1. Don't post your questions in the subject.
2. "The process of calling destructors for automatic objects constructed on
the path from a try block to a throw-expression is called 'stack
unwinding.'"

I don't see how 2 and "do I have to have it if I use classes in C++" fit
together.

Markus

 

[Tony]

1. Don't post your questions in the subject.
2. "The process of calling destructors for automatic objects constructed
on
the path from a try block to a throw-expression is called 'stack
unwinding.'"

I don't see how 2 and "do I have to have it if I use classes in C++" fit
together.

Well I was wondering what the alternative there is, if any, in the face of
exception. Sure, if I say that all exceptions will be handled by terminating
the program, then I can rely on the OS to clean up and/or recover things
like memory and open files (in which case I don't need C++ exceptions at
all). But if I want to try and recover from an exceptional condition and
keep running the program, then the stack needs to be unwound.

I guess the real question is can I avoid using exceptions. I think that is
only possible if I terminate the program upon exceptional conditions. (?)

Tony

 

[Greg]

Well I was wondering what the alternative there is, if any, in the face of
exception. Sure, if I say that all exceptions will be handled by terminating
the program, then I can rely on the OS to clean up and/or recover things
like memory and open files (in which case I don't need C++ exceptions at
all). But if I want to try and recover from an exceptional condition and
keep running the program, then the stack needs to be unwound.

The stack is unwound when an exception is thrown - which is exactly
what should happen, especially if the exception is caught and the
program resumes normal execution. And if the exception is not caught,
then the program will terminate. And unless the program has some
special requirements with regards to freeing resources - exiting
without unwinding the stack generally presents no problems.

Now the first question is whether your program will throw its own
exceptions or not. If the program does not throw exceptions than the
only exceptions that would be thrown would be from the library routines
it calls, such as the ones from the Standard Library. The Standard
Library routines may throw exceptions (for example, a memory allocation
failure when calling new()) and all of the exceptions that may be
thrown are documented.

Exceptions thrown from the Standard Library raises the second question
that has to be answered: whether your program will catch exceptions,
and if so, what kind of exceptions will it catch and where in the
program will it catch them, and what will the program do after having
caught a thrown exception. Generally, it is considered more
user-friendly for a program to catch all exceptions (even if the
program will terminate), in order to perform such actions as logging
the error, notifying the user of the problem, closing files, or any
other actions needed to make its exit as graceful as possible under the
circumstances.

I guess the real question is can I avoid using exceptions. I think that is
only possible if I terminate the program upon exceptional conditions. (?)

C++ exceptions were designed with the assumption that a C++ program
will catch most thrown exceptions and be likely resume its execution
afterwards. Otherwise, the program could simply call abort() or
terminate() as soon as the error was detected.

Greg