Change the name of ArrayBoundsException in druntime

[Andrei Alexandrescu]

Denis Koroskin wrote:
> 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().

But one of the best things possible to do is unwind the stack and fall 
back to a higher position with less state. A function cannot do that, an 
exception can. Why do you guys want to avoid exceptions in one of the 
few cases when they are exactly, but exactly what the doctor prescribed?

Andrei