Bug or feature? std.c.stdlib.exit() breaks RAII

[Ashish Myles]

On Fri, Dec 30, 2011 at 5:43 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
>> Since D
>> could conceivably implement a very safe exit() without an explicit use
>> of Exceptions to get around the "catch Exception() {}" problem you
>> mentioned above, does it make sense to request a safer exit() feature
>> for D?
>
> And how would it do that? The only way in the language to properly unwind the
> stack without returning from each and every function is to throw an Exception.
> If you wanted to do an exit function, it would somehow have to do the exact
> same thing that happens when you throw an Exception except that it's not an
> Exception and isn't caught by catch(Exception) {}. That may not be impossible,
> but I expect that it would complicate things quite a bit. And scope statements
> are designed around exceptions such that if you didn't throw an Exception,
> they wouldn't work properly. The same goes for finally blocks. Also, what is
> the correct thing to do in a situation like this
>

Ok, now there are two issues here:
IMPLEMENTATION: Implementation of a safe_exit() without an explicit
Exception seems to be easy to do at the language level for a
single-threaded program -- you simply have a hidden/system class like,
say, __SystemException from which Exception derives that be comes the
base class of all throwable objects.  __ExitException could then
derive from __SystemException and store the exit value.  But it is not
clear how this would work for multithreaded programs, with which I
have little experience in the context of C++ exceptions. Presumably,
the __ExitException would have to be thrown in all threads and could
interrupt functions that would otherwise not throw exceptions -- I
can't say I understand all the implications.

> try
> {
>    //code
> }
> catch(Exception e)
> {
>    //do stuff
> }
>
> The code in the catch  block assumes that it's always going to be run when the
> code in the try block is not properly completed. If an exit call were made
> from within the try block (be it directly in it or in a function that was
> called inside it), how would the catch block be handled? Without an Exception,
> it would be skipped, what's in that catch block wouldn't be run, and there
> would be no proper cleanup.
>

For cleanup that needs to be done no matter what the exception, I
would just use a finally{} block.

UTILITY: Now, the actual utility of having a safe exit seems to be in
question here. A common use of this is in OpenGL programs (that may be
implicitly multithreaded) where the keyboard handler exit()s when I
hit 'q' or ESC (which is quite common). Moreover, the underlying GUI
framework or other APIs being used may conceivably have multiple
threads and abstract this out for the user.  Is this an unreasonable
use case for a safe exit? Or would this be too difficult to implement
cleanly?