More exception classes into Phobos?

[Jacob Carlborg via Digitalmars-d]

On 2017-03-24 01:25, Walter Bright wrote:

> It's a compelling point, and is the reason why there are many different
> exception types in Phobos.
>
> But in my experience, if an error happens and it is local enough to be
> dealt with specifically, it is checked for directly without needing to
> go through an exception.

The problem is when something in the environment happens that you have 
no control over. Say you're program is supposed to read a file. You 
naturally first check if the file exists, then start reading it. What if 
the file exists on a USB memory which are unplugged in the middle of 
reading the file. If the program knows that the file suddenly doesn't 
exist anymore, then it can ask the user for another file, or plug the 
USB memory back.

> If one is far enough removed from the source of
> the error that one is relying on exceptions, pretty much all one can do
> is the binary "it worked" or "it did not work". The "why it did not
> work" message is then logged or sent to the user, that is the only
> recovery necessary.
>
> The fine grained Exception types is one of those things that sounds
> compelling but just doesn't seem to pay off in practice.

I don't agree. If think you have quite a narrow look at this. Example:

1. An application is internationalized. Showing a generic message in 
English would be pretty bad user experience. Translating the whole 
message directly would be a bad idea, I consider the message in an 
exception from a library an implementation detail. The best would be, in 
my opinion, to have enough information available in the exception type 
to build a proper translated error message for the user.

2. Another example is how the editor I use, TextMate, behaves. If I try 
to save a file I don't have permission to write to, it will ask for my 
password, basically doing the same thing as "sudo" would.

3. If I've opened a file in TextMate, then remove the directory the file 
is located in and then save the file in TextMate, it will show a message 
with the option to create the folder again.

For the last two examples, if the application only got a generic 
Exception or FileException it would not be possible implement these 
features because it would know if the error is that the file doesn't 
exist anymore or if I don't have permission to write to the file.

Talk about just providing a generic exception type. Take this error 
message, using std.file.copy:

std.file.FileException at d.d(3354): /tmp/bar/foo.txt: Permission denied

It doesn't tell if the failed permission is for the source or for the 
target. If failed to read or failed to write.

-- 
/Jacob Carlborg