Change the name of ArrayBoundsException in druntime

[Denis Koroskin]

On Thu, 23 Oct 2008 04:02:22 +0400, Sean Kelly <sean at invisibleduck.org>  
wrote:

> Jarrett Billingsley wrote:
>> On Wed, Oct 22, 2008 at 7:13 PM, Sean Kelly <sean at invisibleduck.org>  
>> wrote:
>>> Errors represent situations which are typically  
>>> non-recoverable--program
>>> logic errors, for example, or situations where data corruption may have
>>> occurred--while Exceptions represent the bulk of normal execution  
>>> errors,
>>> including OutOfMemory conditions.
>>  How, pray tell, is an app supposed to recover from an out-of-memory  
>> condition?
>
> By releasing dynamically allocated memory.  I'd expect some to be  
> released automatically as the stack is unrolled to the catch point  
> anyway.  For example:
>
> void main()
> {
>      try { fn(); }
>      catch( Exception e ) {}
>      int[] x = new int[16384];
> }
>
> void fn()
> {
>      int[] x = new int[16384];
>      fn();
> }
>
> Eventually this app will run out of memory (hopefully before it runs out  
> of stack space) and an OutOfMemoryException will be thrown.  As the  
> stack is unwound, all valid references to this memory will be released.  
>   So the allocation in main() should trigger a collection which frees up  
> all the now-unreferenced memory, thus allowing the allocation in main()  
> to succeed.
>
> For manual recovery, consider an app that does a great deal of internal  
> caching.  On an OutOfMemory condition the app could clear its caches and  
>   then retry the operation.  This is probably a bad example, but I think  
> the general idea of trapping and recovering from such a state is  
> potentially valid.
>
>
> Sean

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().