Change the name of ArrayBoundsException in druntime

[Sean Kelly]

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.

Hm... you're right.  So here we really have two classes of exceptions, 
one concerning the request itself and another concerning meta issues 
like connection failures.  Meta issues can all be caught together as 
Exception, so the only specialized handler would be in handleRequest() 
as something like:

     catch( RequestException e )
     {
         r.tellFailed( e.toString );
     }

Really, all I was getting at is that I don't think it's a good idea for 
there to be no type distinctions at all.  The tricky thing, as you've 
clearly pointed out, is to distill those distinctions to only the 
pertinent ones rather than simply designating a new type for every error.


Sean