DIP33: A standard exception hierarchy

[Steven Schveighoffer]

On Wed, 03 Apr 2013 03:12:56 -0400, Lars T. Kyllingstad  
<public at kyllingen.net> wrote:

> On Wednesday, 3 April 2013 at 07:01:09 UTC, Jacob Carlborg wrote:
>> On 2013-04-02 22:15, Lars T. Kyllingstad wrote:
>>
>>> This illustrates my point nicely!  What does the shell do in this case?
>>> It treats both errors the same:  It prints an error message and returns
>>> to the command line.  It does not magically try to guess the filename,
>>> find a way to get you permission, etc.
>>
>> No, but you do know the difference. It doesn't just say "can't open  
>> file <filename>". It will say either, "file <filename> doesn't exist"  
>> or "don't have permission to access <filename>". It's a huge  
>> difference. I know _what_ went wrong with that file, not just that  
>> _something_ when wrong.
>
> Which is exactly what you'd use FilesystemException.kind and/or  
> FilesystemException.msg for.
>
> I never said there shouldn't be a way to distinguish between file  
> errors, I just said that in most cases, an entirely new exception class  
> is overkill.

Think of it this way, is there a use case where you would want to catch  
the "file not found" exception, but let the "do not have permission"  
exception go through to the next handler?  or vice versa?  This is the  
only reason to have separate classes.

Then we are in the awkward position of what to do if we need to catch  
both.  In that case, you have to have a base class that covers both.

The problem I have with this whole scheme of one class per error type is,  
you inevitably cannot cover everyone's use case, so they end up having to  
catch a base class and then doing the work to figure out what it is  
manually.

-Steve