Change the name of ArrayBoundsException in druntime

[Sean Kelly]

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.


Sean