On Wed, 03 Apr 2013 03:12:56 -0400, Lars T. Kyllingstad
<pub...@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
