Does nothrow mean the function itself does not through exceptions, or that the
function body, as well as any called functions, do not throw? I wonder because
allocating new memory inside a safe nothrow function works, even though I'm
used to "new" allocations throwing exceptions or Out-Of-Memory errors.

Does nothrow mean the function itself does not through exceptions, or that the
function body, as well as any called functions, do not throw? I wonder because
allocating new memory inside a safe nothrow function works, even though I'm
used to "new" allocations throwing exceptions or Out-Of-Memory errors.

As far as I know they have decided to make memory overflow errors, so they are
not exceptions, you can't catch them. Other people will confirm this or not.
Bye,
bearophile

As far as I know they have decided to make memory overflow errors, so
they are

In this case, how would you go about handling out-of-memory situations? A
systems programming language should certainly give the programmer the
option to deal with this.

The short answer: You don't. It's an incredibly bad idea.
The long answer: You catch Error - or OutOfMemoryError if you want that
specific one. So, you could try and catch it and handle it, but most of the
cleanup during the unwinding of the stack gets skipped. scope statements and
destructors don't get called. Your program is not likely to be in state where
it makes any real sense to try and continue. You _can_ do it, but it's a bad
idea.
- Jonathan M Davis

What about if you have an application doing heavy image/video
processing, the application could empty some caches or similar. The
application could still work, just not as fast as with caches.
--
/Jacob Carlborg

The short answer: You don't. It's an incredibly bad idea.
The long answer: You catch Error - or OutOfMemoryError if you want that
specific one. So, you could try and catch it and handle it, but most of
the
cleanup during the unwinding of the stack gets skipped. scope statements
and
destructors don't get called. Your program is not likely to be in state
where
it makes any real sense to try and continue. You _can_ do it, but it's a
bad
idea.
- Jonathan M Davis

What about if you have an application doing heavy image/video processing,
the application could empty some caches or similar. The application could
still work, just not as fast as with caches.

I remember some discussion awhile back about having some sort of scheme in
the GC where you could tell the GC "Hey, in low-memory situations, instead
of bailing out with an Error, call this delegate I'm giving you and I'll try
to clear out my caches to free up some memory." Unfortunately, I don't think
anything's actually come out of that so far. I really hope it does though,
it's a great idea.

The short answer: You don't. It's an incredibly bad idea.
The long answer: You catch Error - or OutOfMemoryError if you want that
specific one. So, you could try and catch it and handle it, but most of
the
cleanup during the unwinding of the stack gets skipped. scope statements
and
destructors don't get called. Your program is not likely to be in state
where
it makes any real sense to try and continue. You _can_ do it, but it's a
bad
idea.
- Jonathan M Davis

What about if you have an application doing heavy image/video processing,
the application could empty some caches or similar. The application could
still work, just not as fast as with caches.

I remember some discussion awhile back about having some sort of scheme in
the GC where you could tell the GC "Hey, in low-memory situations, instead
of bailing out with an Error, call this delegate I'm giving you and I'll
try to clear out my caches to free up some memory." Unfortunately, I don't
think anything's actually come out of that so far. I really hope it does
though, it's a great idea.

Not a bad idea. It would still have to throw an OutOfMemoryError if it really
couldn't free enough memory, but it would still improve the situation for
anyone looking to use caches or anything else which could have its memory
freed and still allow the program to function correctly if the memory
consumption gets too high.
- Jonathan M Davis

As far as I know they have decided to make memory overflow errors, so
they are

In this case, how would you go about handling out-of-memory situations? A
systems programming language should certainly give the programmer the
option to deal with this.

The short answer: You don't. It's an incredibly bad idea.
The long answer: You catch Error - or OutOfMemoryError if you want that
specific one. So, you could try and catch it and handle it, but most of the
cleanup during the unwinding of the stack gets skipped. scope statements and
destructors don't get called. Your program is not likely to be in state where
it makes any real sense to try and continue. You _can_ do it, but it's a bad
idea.
- Jonathan M Davis

Does nothrow mean the function itself does not through exceptions, or that
the function body, as well as any called functions, do not throw? I wonder
because allocating new memory inside a safe nothrow function works, even
though I'm used to "new" allocations throwing exceptions or Out-Of-Memory
errors.

A nothrow function must not allow any Exceptions escape from it. So, it must
either catch them all or it must only call functions which are nothrow and
throw nothing itself.
An Error can still escape a nothrow function (though you may not be able to
throw one manually, I don't know), because when an Error occurs, your program
is pretty much toast. You're not normally supposed to try and catch those.
- Jonathan M Davis

As far as I know they have decided to make memory overflow errors,
so
they are

not exceptions, you can't catch them. Other people will confirm this
or not.
In this case, how would you go about handling out-of-memory
situations? A systems programming language should certainly give the
programmer the option to deal with this.

The short answer: You don't. It's an incredibly bad idea.
The long answer: You catch Error - or OutOfMemoryError if you want that
specific one. So, you could try and catch it and handle it, but most of
the cleanup during the unwinding of the stack gets skipped. scope
statements and destructors don't get called. Your program is not likely
to be in state where it makes any real sense to try and continue. You
_can_ do it, but it's a bad idea.
- Jonathan M Davis

What about if you have an application doing heavy image/video
processing, the application could empty some caches or similar. The
application could still work, just not as fast as with caches.

Things do _not_ get cleaned up properly when an Error is thrown. Destructors,
finally blocks, and scope statements are skipped when any type of exception
which is not derived from Exception (directly or indirectly) is thrown. Errors
are considered unrecoverable.
Now, you _can_ catch Errors. You _can_ try and continue to execute your
program. But, there are no guarantees that your program is still in a sane
state, because anything which could have been affected by destructors, finally
blocks, and scope statements being skipped could be in a state which your
program does not expect and cannot handle.
Read page 307 of TDPL. It talks about "nothrow Functionsa and the Special
Nature of Throwable." What it says applies to all throwables which are not
derived from Exception. That's why when you have a nothrow function, like this
void func() nothrow
{
try
throwFunc();
catch(Exception e)
assert(0, "It threw!");
}
void throwFunc()
{
throw new Exeception("Exception!");
}
catching Exception is enough. Anything not derived from Exception is not
considered in nothrow and is considered unrecoverable. So, attempt to recover
from an OutOfMemoryError at your own peril.
In the case of your image/video application, it might be able to recover and
continue if you were able to catch the OutOfMemoryError at its source before
it started propagating up the calcl stack, but as soon as it starts skipping
stuff that a normal Exception wouldn't have skipped, your program is
effectively
in an invalid state. If you really wanted to do what you describe, you'd
probably want to use custom memory allocators, which is on the todo list, I
believe (and is one of the major reasons why Andrei isn't farther on
std.container yet; he wants to sort out his custom memory allocator scheme
first). But trying to catch and recover from an Error is generally a _very_ bad
idea.
- Jonathan M Davis