Change the name of ArrayBoundsException in druntime

[Andrei Alexandrescu]

David Gileadi wrote:
> 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.

It's very possible. Parameterizing Exception the same way Tuple is 
parameterized (with e.g. module name and name/value type pairs) is a 
great idea!

Andrei