Change the name of ArrayBoundsException in druntime

[Jesse Phillips]

On Wed, 22 Oct 2008 17:02:22 -0700, Sean Kelly 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 a good reason for keeping it an exception (ie recoverable) is 
that out of memory may not be the fault of the program. A completely 
correct program can be given an out of memory error, especially if 
another program (like your example) eats it up, would you want your whole 
system to come to an end?