Exceptions on windows

[txe]

@RX14 , it's a question related to #4832. I just wanted to continue here because the conversation can turn out to be long. You said:

I deeply disagree with creating a WinError class. Errno is platform-specific, and it needs to go. Exception hierarchy should never depend on the platform you're running on.

For now mapping to errno will work but we must remove errno before the first release. We should abstract the exception hierarchy to be platform specific. There's a good document on how python did this that we can take inspiration from. Doing that is beyond the scope of this pr though.

I'm a bit confused by these words so decided to take "how python handles exceptions now" as a core statement :)

There is PEP 3151 which describes the OS and IO exception hierarchy in python. So basically, in spite of the fact that python has a number of different exceptions, it only uses one OSError when it comes to work with a system function which returns a system-related error.

OSError has errno attribute under Unix but errno and winerror attributes under Windows. Under Windows, the errno attribute is loosely determined from the Windows error code, mapper source.

For me, Errno class in crystal looks the same as OSError in python. So did you suggest to add winerror field into Errno class?

[RX14]

That python PEP keeps OSError for compatibility reasons, we don't need to be compatible and so we should remove Errno. A single exception type which represents multiple different logical exceptions is surely bad design. We should design an exception hierarchy which represents the error which actually happened, not represents the platform-specific way that error was signaled to you (like Errno does). Yes, it's difficult but surely it's worth it. I'm tired of checking errno.value every time I catch Errno and this is a perfect time to fix this cruft from ruby.

[txe]

OK, now I see your point. But I don't think it's a perfect time for that thing, it's just beyond my competence.
Is there any way to simplify the situation with exceptions under Windows? I really don't want to do big changes because it would slow down my work on PRs.

Can I suggest the following things:

1. leave Errno class as it is
2. use Errno for exceptions under Windows like this, for example:

def win_error(message)
    Errno.new (message, winerror_to_errno(LibC.get_last_error()))
end
....
raise win_error("some message")

3. or use class WinError < Errno where WinError simply initializes Errno like win_error mentioned before.

[ysbaddaden]

I suppose subclassing WinError < Errno is okayish.

@RX14 Ruby has per errno exception classes that can be rescued, you must check Errno.value in Crystal because #445 was never merged.

[RX14]

As I said, its perfectly fine to translate windows errors to errnos right now, so we can get this merged.

@ysbaddaden I don't want to have Errno::ECONNRESET, I want IO::ConnectionResetError. One is just so much more readable and cleaner. We must remove errno as a subclass of Exception, as it is C legacy and absolutely not good design.

[txe]

OK

[RX14]

Should we open another issue on replacing errno with many, smaller, descriptive exceptions?