On Wednesday, 6 June 2012 at 13:26:09 UTC, Steven Schveighoffer
wrote:
On Wed, 06 Jun 2012 05:13:39 -0400, Lars T. Kyllingstad
<pub...@kyllingen.net> wrote:
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
wrote:
On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
I don't agree that OutOfMemory is critical:
--> make it an exception ?
No. What we need is a non-throwing version of malloc that
returns NULL. (throwing version can wrap this). If you want
to throw an exception, then throw it there (or use enforce).
With some sugar:
auto a = nothrow new Foo; // Returns null on OOM
Then, ordinary new can be disallowed in nothrow code.
That doesn't work, new conflates memory allocation with
construction. What if the constructor throws?
The constructor would have to be marked nothrow as well.
Actually, that is currently the case:
class Foo
{
this() { }
}
void bar() nothrow
{
auto f = new Foo;
// Error: constructor this is not nothrow
// Error: function 'bar' is nothrow yet may throw
}
The only difference between "new" and "nothrow new" is that the
latter would return null on allocation failure instead of
throwing an OutOfMemoryError.
Based on this discussion, I gather that one of the big problems
is that the compiler is free to elide stack unwinding code for
nothrow functions, despite the fact that they can in fact throw
Errors. One solution would therefore be to disallow *all*
throwing from nothrow functions, including Errors.
Besides OutOfMemoryError, I can only think of two other Errors
that would make this a hassle: AssertError and RangeError.
However, both of these signify problems with the program logic,
and unwinding the stack is probably a bad idea anyway, so why not
simply make these abort()?
-Lars
