Change the name of ArrayBoundsException in druntime

[Andrei Alexandrescu]

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

I understand your motivation. But you can easily implement all of that 
within client code without changing anything anywhere. Notice that the 
problem is more general, e.g. if creating a socket fail you might ask 
the user to plug a cable or start a wireless card etc. Just catch the 
exception at the appropriate level, take the appropriate measure, and 
goto RETRY. :o)


Andrei