Change the name of ArrayBoundsException in druntime

[Lars Kyllingstad]

KennyTM~ wrote:
> 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...
> 

Even though the last suggestion was partially meant as a joke, I think 
it is actually a good idea. One could have a third hierarchy of 
exception classes, for exceptions like OutOfMemoryException that one 
should be able to catch, but that shouldn't be caught by default along 
with other exceptions. Sort of a "middle ground" between Exception and 
Error.

Not sure about the name "ChallengingException", though. ;) How about 
SpecialException, CriticalException or something like that?

-Lars