Change the name of ArrayBoundsException in druntime
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Oct 23 11:40:22 PDT 2008
Sean Kelly wrote:
> Denis Koroskin wrote:
>>
>> I think that OutOfMemoryException should *not* be recoverable.
>> Instead, language should provide some hookable callback (like
>> onOutOfMemoryError()) which is called when memory limit is reached so
>> that program may free some unused memory (which is held by user since
>> it is not garbage-collected) and tries to allocate the memory again
>> without failure (return true from callback). User might decide to
>> re-throw some other kind of *exception*, like
>> NotEnoughMemoryException(), to catch and recover, or pass it (return
>> false from callback) which in turn will finally throw OutOfMemoryError().
>
> This is a fair point, but how does one implement this safely? Let's say
> for the sake of argument that onOutOfMemoryError() can be hooked by the
> user and may try to recover. Now:
>
> auto x = new int[BIG_NUMBER];
>
> Let's say that gc_malloc() is implemented like so:
>
> void* gc_malloc( size_t sz )
> {
> void* ptr;
> do
> {
> ptr = doMalloc(sz);
> if( ptr is null )
> onOutOfMemoryError();
> } while( ptr is null );
> return ptr;
> }
>
> Now let's assume that the first attempted allocation fails and
> onOutOfMemoryError() frees some memory rather than throwing so the
> allocation is attempted again. But BIG_NUMBER is so darn big that the
> allocation fails again. And once again onOutOfMemoryError() tries to
> free some memory and returns instead of throwing. Is there any way to
> structure the recovery mechanism to avoid this situation given that
> onOutOfMemoryError() has no idea that it's being called in such a loop?
> gc_malloc() could certainly give up and throw after a certain number of
> failed attempts, but putting the onus on the caller of
> onOutOfMemoryError() to deal with this situation is not reasonable in my
> opinion.
Perfectly put. Again: why prevent use of exceptions for the one case
that they fit the best?
Andrei
More information about the Digitalmars-d
mailing list