Change the name of ArrayBoundsException in druntime

[Robert Fraser]

Jesse Phillips wrote:
> On Fri, 24 Oct 2008 16:04:53 -0700, Robert Fraser wrote:
> 
>> Bill Baxter wrote:
>>> On Fri, Oct 24, 2008 at 10:42 AM, Robert Fraser
>>> <fraserofthenight at gmail.com> wrote:
>>>> Sean Kelly wrote:
>>>>> Perhaps I'm simply getting old... when did memory use become
>>>>> irrelevant?
>>>>>  I grant that making an application exception safe is more difficult
>>>>>  if out
>>>>> of memory conditions are considered recoverable, but I don't think
>>>>> it's tremendously more difficult.
>>>> I'm currently studying Computer Engineering at university. I don't
>>>> think a single programming course I've taken has _mentioned_ running
>>>> out of memory (next quarter I'm taking Operating Systems, so hopefully
>>>> that will). One class mentioned memory complexity as a side issue, but
>>>> never got into it. Even at work, I've never been asked to think about
>>>> it.
>>> People do still develop for embedded devices with small memory and/or
>>> no virtual memory.
>>> I'm pretty sure it's still a serious concern if you live in that world.
>>>
>>> --bb
>> I'm not saying it doesn't come up in practice; I'm saying developers are
>> trained not to think about it in most cases. And programming to handle a
>> small amount of memory is a different problem than programming to
>> gracefully fail when the program runs out of memory (for example, my
>> program might only use 10k of RAM... but if that 10k isn't there, it
>> might just crash with an error message).
>>
>> The problem with an OutOfMemoryError being treated as an Exception is
>> that if there are many catch(Exception) blocks, an out-of-memory error
>> will propagate logic bugs across the program (since no one is cleaning
>> up the memory, most allocations will fail). So instead of a nice, clean
>> error, the suer will experience weird and frustrating behavior that
>> doesn't mention memory at all.
> 
> The problem with it being an error is that the programmer has no way to 
> catch and remain usable, 

Sure there is:
catch(OutOfMemoryError)

Just like in Java or .Net. The only difference is that it's not caught 
by a general catch(Exception)

> leaving the user blissfully unaware he needs to 
> buy more ram. If there are many catch(Exception)'s around, the programmer 
> needs to rethink what he is doing when creating a stable program.

Probably. But when you have a team of 300 programmers, this is a bit 
harder to do, and catch(Exception) _is_ a powerful tool for generalized 
recoverable error handling.

> D doesn't force a try or throw of exceptions for this very reason; people 
> usually use the catch(Exception) because they don't know what needs to be 
> caught and don't care but are forced to catch it, not because their 
> program is crashing from an exception (well, that is what I do).

People also use it to say to the user "this didn't work; try something 
else"? In 99% of cases, this is fine, but when memory is involved, the 
programmer has a whole lot more to think about and would often want to 
catch the memory exception at a higher level.