Change the name of ArrayBoundsException in druntime

[Andrei Alexandrescu]

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