Change the name of ArrayBoundsException in druntime

[Robert Fraser]

Andrei Alexandrescu wrote:
> Robert Fraser wrote:
>> Andrei Alexandrescu wrote:
>>> Jarrett Billingsley 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.
>>>
>>> I agree. In fact I wanted to ask you all the following question. What do
>>> you think about the current exception hierarchy in phobos? I think it is
>>> terrible. Each module in std you open, the first piece of code to be
>>> seen is the "class ThisModuleNameException" definition. In many (most?)
>>> cases the module-specific exception does absolutely nothing in addition
>>> to its base class. The putative reader (including me) tends to scroll 
>>> non-critically over that passage without even blinking, mumbling in a 
>>> trance - of course, yes, each module should define at least one 
>>> exception type.
>>>
>>> Until one day when you stop scrolling and say, wait a minute. This 
>>> all is repetition. And there are alternatives to catching by type - 
>>> you can catch the base type and consult a field. And in fact I don't 
>>> remember seeing code that depends on exceptions thrown from different 
>>> modules having different types. There's something wrong here!
>>>
>>> I think most exception classes in phobos should be yanked if it's 
>>> possible for their functionality (often nil) to be moved in the 
>>> Exception base class. The module name should be a member. If someone 
>>> needs to deal with an exception thrown from a specific module, they 
>>> can always inspect the field. We don't need a huge hierarchy for that.
>>>
>>>
>>> Andrei
>>
>> Yes, you _could_ use a field... but the "catch a subclass" style is 
>> already there and is supported by the language, so _why_ use a field? 
>> Which of the following is easier?:
>>
>> Option A:
>> ---------
>> try
>> {
>>      new Socket(30587);
>> }
>> catch(SocketException e)
>> {
>>      printf("Could not open socket\n");
>> }
>>
>> 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.
> 
> 
> Andrei

So in most cases you don't need it... But why throw it out for the cases 
in which you do (or make it harder to use). In other words, is there any 
_harm_ being done by having a large exception hierarchy?