Change the name of ArrayBoundsException in druntime

[Denis Koroskin]

On Thu, 23 Oct 2008 17:47:52 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

You can do that, of course, just don't handle the onOutOfMemory custom  
callback (per my proposal).

> 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

My concern is to avoid program flow interrupt and fall-back to some  
recovery code if possible. One of such cases is OutOfMemoryException.

For example, I recieve some network message. An object is constructed and  
about to be inserted into the message list. Imagine that an  
OutOfMemoryException is thrown during the insertion. It is quite hard (if  
possible) and not generally disirable to revert network state: I have to  
emulate that message is not recieved yet so that I get it later (at a  
second attempt, after OutOfMemory exception is processed and some memory  
freed), etc. Besides, where would you put the catch(OutOfMemoryError)  
code? Far from the exception source point, most likely, which is even  
worse for recovery.

The solution I would prefer is to avoid that situation at all! No memory?  
Fine, I'll clean this memory pool and that one, too. Try again, please!  
Still no memory? Then re-throw the exception so that upper forces handle  
the situation.

I don't say that exception recovery is not needed - of course it is! - but  
I prefer to avoid it if possible. It is just safer.

Leave the user unaware that an out of memory error has been occured and  
recovered from is my best wish.