Change the name of ArrayBoundsException in druntime

Robert Fraser fraserofthenight at gmail.com
Thu Oct 23 03:45:22 PDT 2008


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

Didn't see this discussion before I went off my tirade. I agree it's 
recoverable and in a perfect world this would be so, but look through 
any large codebase for how many catch(Exception) blocks there are. I'll 
bet you that NONE of the general catch(Exception) blocks (except the 
ones that print an error and exit the program) expect to see, or are 
prepared for, an out of memory exception.

Asking programmers to think about out of memory errors is too much. 
We're trained to assume computers have infinite memory and when they run 
out, the system/runtime is supposed to do drastic things like crashing 
our programs - not start introducing strange logic errors all over the 
place because programmers didn't realize their catch(Exception) blocks 
had to deal with more than "file doesn't exist"



More information about the Digitalmars-d mailing list