https://issues.dlang.org/show_bug.cgi?id=13620

          Issue ID: 13620
           Summary: Consolidate / clean up exception types used for OS
                    exceptions
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
          Assignee: nobody@puremagic.com
          Reporter: thecybershadow@gmail.com

Currently, Phobos is inconsistent in how it implements exceptions caused by OS errors:

- std.file declares an exception type specific to the module (FileException),
even though there is no technical reason why a file operation is treated
differently than other I/O or OS operations.
- Some modules (e.g. std.mmfile, std.process) "borrow" these exception types
despite not actually using functionality in std.file.
- Whether a certain Phobos function uses a C function or an OS API to implement
something is an implementation detail. Documenting whether an ErrnoException or
some other exception type is thrown is an abstraction leak.
- Some functions (e.g. Clock.currTime) throw different, unrelated exception
types on different platforms.
- Because of all the confusion, occasionally the incorrect exception type is
used (e.g. passing GetLastError to strerror). A notable example is
FileException, which interprets the error code differently depending on the
platform.

To remedy the situation, I suggest:

0. Define WindowsException and wenforce, in the style of ErrnoException and
cenforce (already done).

1. Define an abstract std.exception.OSException class, derived from Exception. This class has an "errno" field, the meaning of which depends on the subclass.

2. Make ErrnoException and WindowsException subclasses of OSException.

3. Replace FileException with an alias to OSException.

4. Update all documentation which mentions FileException to use OSException instead.

5. Review all uses of FileException, ErrnoException and other thrown exceptions thrown on OS error conditions to use ErrnoException/cenforce and WindowsException/wenforce as appropriately.

This should clean things up without breaking any code.

--