More exception classes into Phobos?

[Jacob Carlborg via Digitalmars-d]

On 2017-03-28 22:10, Jonathan M Davis via Digitalmars-d wrote:

> 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.

The application can ask for a password, i.e. "sudo". That is what 
TextMate is doing.

> 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.

If the file doesn't exist the application can ask the user for another 
file (reading). If a directory doesn't exist it can ask the user if it 
should create the directory (writing a file), again, that is what 
TextMate is doing.

> 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.

But the standard library shouldn't decide that. It should just provide 
as much information as possible to let the developer of the application 
decide what to do with the error.

> 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.

Ok, I apologize for not look at exactly what FileException contains. 
Although I still think it's the wrong way of providing that information. 
In my opinion it should be it's own exception type, otherwise I would 
need to catch _all_ FileException exceptions even though I cannot handle 
them. Then look at the errno code to check if I can handle it and 
otherwise rethrow the exception.

In addition to that I think that error originate from a call to a C 
function, indicated by the presence of "errno", is an implementation 
detail which should not be exposed outside of Phobos. It's also slightly 
awkward from a Windows point of view that the Unix name "errno" is used 
for the field. On Windows it's actually "GetLastError" that is used to 
populate the "errno" field not the "errno" function.

It's missing a source and target field (in the case of "copy"). I don't 
know which files failed, and based on the error message I don't even 
know if it was the source or target that failed. It wouldn't be right 
either to add those fields to FileException because not all operations 
have a source and target. Yet again it shows that we need more specific 
exception types.

In my opinion the following information should be available in the 
exception type for an exception to due a failed copy operation, either 
as a field or in the type itself:

* file and line number - where the exception originated
* message - generic error message for debug aid and the most simple form 
of error handling
* source and target - the resources (file/directory) that were involved 
in the operation
* failed resource - somehow indicating if it was the source or target 
that failed
* operation - that operation that failed, "copy" in this case
* error - what actually went wrong, "permission denied" in this case

-- 
/Jacob Carlborg