On 06/06/2012 07:18 PM, Lars T. Kyllingstad wrote:
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
In the current implementation, in contract checking may catch
AssertErrors and resume the program normally.
