Change the name of ArrayBoundsException in druntime

[Andrei Alexandrescu]

Andrei Alexandrescu wrote:
> Sean Kelly wrote:
>> 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.
>>
>> It may be different in a user application, but in services it's fairly 
>> common to have specialized code for handling different exception 
>> types.  And more importantly, it's common to want different exception 
>> types to propagate to different levels for handling.  Sure, one could 
>> use a generic exception handler at each level that rethrows if the 
>> detected type isn't one that handler cares about but why do this when 
>> filtering on type is a language feature?
>>
>> For example, let's say I have a network service that's backed by a SQL 
>> database.  My main program loop may look something like this:
>>
>>     bool connected = false;
>>     while( true )
>>     {
>>         try
>>         {
>>             while( true )
>>             {
>>                 auto r = acceptRequest();
>>                 scope(failure) r.tellFailed();
>>                 if( !connected )
>>                     connectToDB();
>>                 handleRequest( r );
>>             }
>>         }
>>         catch( SqlException e )
>>         {
>>             connected = false;
>>             log( e );
>>         }
>>         catch( Exception e )
>>         {
>>             log( e );
>>         }
>>     }
>>
>>     ...
>>
>>     void handleRequest( Request r )
>>     {
>>         scope(failure) r.tellFailed( "General error" );
>>
>>         try
>>         {
>>             // process r
>>         }
>>         catch( AuthException e )
>>         {
>>             r.tellFailed( "Authentication failure" );
>>         }
>>         catch( ValidationException e )
>>         {
>>             r.tellFailed( "Invalid request format" );
>>         }
>>     }
>>
>> Being able to trap specific types of exceptions makes this code 
>> cleaner and more succinct than it would be otherwise.  If this weren't 
>> possible I'd have to trap, check, and rethrow certain exceptions at 
>> different levels to ensure that the proper handler saw them.
> 
> Thanks for fueling my argument. There's duplication in code examples, as 
> in many other examples I've seen in favor of by-type handling.
> 
> First example:
> 
>         catch( Exception e )
>         {
>             if (e.origin = "sql") connected = false;
>             log( e );
>         }
> 
> Less code and no duplication. Second example is even starker:
> 
>         catch( AuthException e )
>         {
>             r.tellFailed( e.toString );
>         }
> 
> Clearly the need is to factor in the message to print in the exception, 
> at least in this case and many like it.
> 
> 
> Andrei

By the way, this each-exception-has-its-type crap is my #2 pet peeve 
after "Follow carefully my pocket watch... OO is good for everything... 
OO is good for everything... to use, inherit... to use, inherit..."

Andrei