Change the name of ArrayBoundsException in druntime

[Jesse Phillips]

On Sat, 25 Oct 2008 15:45:51 -0700, Robert Fraser wrote:

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

Oops, from past discussions about the difference I somehow got the idea 
that an Error couldn't be caught.

While out of memory still falls under recoverable, I can see why putting 
greater importance over other exceptions would be good.