[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RFE: refman - adding mention of os.exit not closing variables with default arguments.
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Mon, 29 Jun 2020 20:30:46 +0200
On 25/06/2020 19:56, Coda Highland wrote:
On Thu, Jun 25, 2020 at 11:30 AM Lorenzo Donati <email@example.com>
Yep. Thanks. I did know the existance of those functions. After the the
brief discussion with Francisco Olarte, I wonder whether all those
standard functions to perform exit are really useful.
It seems that exiting an application is quite complicated and requires
custom code that relies both on the os and the specific application.
I wonder how many people really use all this C standard facilities
instead of writing their own exit function.
In general, the "standard" facilities are only useful as an emergency abort
-- when your application has entered a state that can't be recovered from,
you can use the exit() family of functions to at least try to terminate
without making too much of a mess. Things that absolutely must be properly
handled even during an emergency abort can then provide an atexit callback.
Otherwise, you should always try to end the program by setting things up so
that control flow bubbles up to main(), which then returns as normal. (As
mentioned, typically this is done by flagging the event loop to stop
That said, most people don't write their own either. They use one of the
countless event handling libraries (glib, libuv, the Windows message pump,
etc.) to abstract out the nitty-gritty details.
Thanks for the information. I've seen this pattern in the past, but now
you confirm it's common and, as I see, recommended practice.
In C++ you can throw an exception, which will unwind the stack properly on
the way out, and if main() doesn't catch it, then it calls abort(). C has
no standard equivalent.
Mmmh. So does this mean that C applications have quite a hard time when
they need to quit in a clean way when executing some code with a deep
call stack, right?