Change the name of ArrayBoundsException in druntime

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Sergey Gromov wrote:
>> Thu, 23 Oct 2008 08:43:04 -0500,
>> Andrei Alexandrescu wrote:
>>> Robert Fraser wrote:
>>>> Option B:
>>>> ---------
>>>> try
>>>> {
>>>>     new Socket(30587);
>>>> }
>>>> catch(Exception e)
>>>> {
>>>>     if(e.type == ExceptionType.Socket)
>>>>         printf("Could not open socket\n");
>>>>     else
>>>>         throw e;
>>>> }
>>> I think you'd be hard-pressed to justify the "if" inside the second 
>>> example. You couldn't create a Socket, period. It doesn't matter where 
>>> exactly the exception was generated from.
>>>
>>> That's one thing about large exception hierarchies: everybody can come 
>>> with cute examples on how they could be useful. As soon as the rubber 
>>> hits the road, however, differentiating exceptions by type becomes 
>>> useless.
>>
>> If you try every function separately, yes.  But I think that the line 
>> between recoverable and non-recoverable exceptions is arbitrary and 
>> depends on the situation.  It makes sense to try/catch a transaction, not 
>> separate calls.  I can retry connection transaction if the socket open 
>> fails, but the whole upper-level transaction should fail if there is a 
>> database inconsistency or out of memory.
>
> I agree, but there's no need for a million types to support that.

I agree that there's both a reason for subclassing and a reason for 
parameterizing.

I don't want only one Exception class in the whole hierarchy that is 
parameterized as given in the example, but I also hate it when the reason 
for the exception is only implemented by the type of the exception.

A good example is many OS errors, those should be parameterized on the errno 
(and should provide an easy way to build the string from strerror).

-Steve