Change the name of ArrayBoundsException in druntime

[David Gileadi]

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

Just an ill-considered idea from someone who has no idea whether it is 
even technically possible:

try
{
     new Socket(30587);
}
catch(Exception!(SocketConnect) e)
{
     printf("Could not open socket\n");
}
catch(Exception ex)
{
     printf("Serious trouble--I probably shouldn't have caught this at 
all!\n");
}

Granted, you'd still need to define SocketConnect and its ilk, but since 
they'd be simple (and in some cases  empty) data containers they would 
be quick and easy to define, especially since you wouldn't need to 
implement all of Exception's constructors.

Of course, this is back to catching by type again, so maybe it's not a 
good idea even if it is possible.