Change the name of ArrayBoundsException in druntime

[KennyTM~]

Robert Fraser wrote:
> Sean Kelly wrote:
>> Denis Koroskin wrote:
>>> On Wed, 22 Oct 2008 16:22:02 +0400, Jarrett Billingsley 
>>> <jarrett.billingsley at gmail.com> wrote:
>>>
>>>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet at gmail.com> 
>>>> wrote:
>>>>> I think the name ArrayBoundsException should be changed to a more 
>>>>> general
>>>>> name like BoundsException, OutOfBoundsException or
>>>>> IndexOutOfBoundsException. Then you can use the exception in every 
>>>>> class
>>>>> that have some sort of index operation and not just for an array/array
>>>>> class.
>>>>>
>>>>
>>>> 2nded.
>>>
>>> Agreed. BTW, why it is not an Error but Exception?
>>
>> The Error class was created shortly before release and I didn't get 
>> around to reclassifying the exceptions in druntime.  From memory 
>> though, I think that OutOfMemoryException and UtfException should 
>> remain as-is, but the remaining exceptions should probably be errors.  
>> Any objections?
>>
>> And as for ArrayBoundsException... how about IndexOutOfBoundsError. 
>> It's long, but probably the most self-explanatory.  Also, any value in 
>> retaining ArrayBoundsError and having it subclass this?  I'd think 
>> not, but figured I'd ask anyway.
>>
>>
>> Sean
> 
> Ah NOOOOO! Please don't make an out of memory catchable with a plain 
> catch(Exception) .... In most programs... pretty much every non-trivial 
> desktop application I can think of... an out-of memory state is 
> basically unrecoverable. In the few cases it would need to be, there 
> would need to be significant handling code, and that would have to be at 
> the right location in the program (i.e. when first opening a file), not 
> in the closest catch-all block some intern down the hallway may have 
> thrown in.
> 
> Out of memory is an Error subclass in Java and C#, so there's precedent 
> there. catch(Exception) shouldn't be used - but it is, quite often, so 
> things that would cause issues that a user could not normally be 
> expected to recover from should be Error subclasses.
> 
> Indexing I could see being an exception since that's deterministic and 
> the user's fault. So I guess I disagree on both counts ;-P. Although 
> since index errors don't appear in release modes in D, that gives more 
> case for it to be an Error.

Make OutOfMemoryException the own subclass of Throwable? Then we have

Throwable
   Exception
   Error
   OutOfMemoryException

or we maybe we can have (jokingly)

Throwable
   Exception    // Recoverable
   Error        // Should not be recoverable
   ChallengingException  // Recoverable but I won't touch it.
     OutOfMemoryException // Let programmer to force GC to release memory
     CPUOnFireException   // Let programmer to call local fire station 
through modem.
     // etc...