Removed Type-Defect label.
Added Type-Enhancement, Area-IO, Triaged labels.

The plan is as follows:

1. Remove DirectoryException and LinkException, so we only use FileException.
2. Roll out specific FileExceptions, such as NotFoundException, PermissionException, etc. The list is not decided upon yet.

We're landing 1) ASAP, as that's the only breaking part of this change.

Set owner to @skabet.
Added Accepted label.

SGTM, though I would probably prefer IOException over FileException since it will be confusing to get a FileException from a directory method.

IOException is already there. I would just like to group file-system related exceptions under one item, thus why I kept FileException. I suppose the right name would be FileSystemException, but it's rather long. Bob, what do you think?

I would just like to group file-system related exceptions under one item, thus why I kept FileException.

Do you have use cases where a user might want to catch FileException and not also catch other non-File IOExceptions? If not, I would just get rid of FileException.

I suppose the right name would be FileSystemException, but it's rather long.

Yeah, that's pretty painful, especially given that this is one of the most common types to actually intentionally catch.

Do you have use cases where a user might want to catch FileException and not also catch other non-File IOExceptions? If not, I would just get rid of FileException.

If we create a hierarchy, I want the user to be able to catch all, and only, file-system exceptions. But as you say, this would be the only scenario where you would have to spell out FileSystemException - normally people can just to IOException or e.g. NotFoundException.

I'm not sure if I have a good intuition of what's a FileSystemException and what's an IOException. I worry that users catching the first might actually want to catch the second and not realize it. If you think it's a useful distinction, then go for it, but my inclination is to keep exception hierarchies pretty shallow.

Added this to the Later milestone.
Removed Priority-Unassigned label.
Added Priority-Medium label.

Removed Area-IO label.
Added Library-IO, Area-Library labels.

Removed the owner.
Added Triaged label.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.

I'm also a little interested in this. Languages like Python will raise a FileNotFound error and not just an IoError.
I guess this will have to be changed in Dart 3, unless it won't break compatibility?

If you try to perform an IO operation on a non-existent entity, you'll get either a FileException or a DirectoryException whose OSError has an errorCode of 2 on Mac/Linux and 3 on Windows...

I agree with the issue overall but do you have a repro where a non-existent file generates a errorCode or 3 on Windows?

I just tested with File.openRead and get errorCode 2.

PR in progress here: https://dart-review.googlesource.com/c/sdk/+/267280

Fixed in b75f8aa