On Tuesday, March 28, 2017 20:07:01 Jacob Carlborg via Digitalmars-d wrote:
> On 2017-03-28 11:25, Walter Bright wrote:
> > If you received an IOException instead, you're no better off.
>
> No, I agree. But I have not argued for or against a standardize
> exception hierarchy. I've argued that we need more specific error types
> (either as a hierarchy or flat structure).
>
> > As Andrei observed, it is the message that's the problem, not the
> > exception type.
> It's an issue with both. It's an issue with the exception type because I
> cannot really handle the error in any sensible way. In my opinion the
> error message is more of a debug aid.
Agreed. Error messages are just for reporting what went wrong, not for being
used to decide what the code should do. That depends on the exception type
(assuming that it makes sense to respond based on the type of the error), or
it depends on addition information that a specific exception type provides
for the program to look at and use in order to figure out how to respond.
> > In general, I think a lot of the issues you brought up are inadequate
> > messages, or trying to solve the problem at the wrong level of the
> > function call hierarchy (i.e. too far up).
>
> void main()
> {
> import std.stdio;
>
> try
> copy("/tmp/foo.txt", "/tmp/bar/foo.txt");
> catch (FileException e)
> {
> // handle permission error?
> }
> }
>
> How should I handle a permission error in the above example? It's not
> possible to do so without parsing the error message. This is catching
> the exception as close as possible to the source (without modifying
> Phobos).
And how would you ever handle a permission error? If you don't have the
permissions for the file, you don't have permissions for the file. And
trying to read a file that you don't have permissions for isn't really any
different from if the file didn't exist. As far as I can tell, the only
difference is in what you report to the user or log, and if that's the case,
simply having a better error message is all that it makes sense to do. I
expect that someone could come up with a case where knowing exactly what
went wrong when trying to read or write a file could be dealt with
programmatically if the program knew exactly what went wrong, but in most
cases, it really doesn't matter. Either the operation succeeded, or it
didn't. The why doesn't matter beyond reporting it to the user or logging
it. The program is going to do the same thing regardless.
However, if you do want to respond to permission errors more specifically
and do something differently with them than with other error cases,
FileException _does_ have an errno member to get at the same information a C
program would have. So, FileException is already providing additional
benefit beyond what a plain Exception provides.
- Jonathan M Davis
