mirror of
https://github.com/rust-lang/rust.git
synced 2025-04-28 02:57:37 +00:00
fdd9a07147
More ErrorKinds for common errnos From the commit message of the main commit here (as revised): ``` There are a number of IO error situations which it would be very useful for Rust code to be able to recognise without having to resort to OS-specific code. Taking some Unix examples, `ENOTEMPTY` and `EXDEV` have obvious recovery strategies. Recently I was surprised to discover that `ENOSPC` came out as `ErrorKind::Other`. Since I am familiar with Unix I reviwed the list of errno values in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html Here, I add those that most clearly seem to be needed. `@CraftSpider` provided information about Windows, and references, which I have tried to take into account. This has to be insta-stable because we can't sensibly have a different set of ErrorKinds depending on a std feature flag. I have *not* added these to the mapping tables for any operating systems other than Unix and Windows. I hope that it is OK to add them now for Unix and Windows now, and maybe add them to other OS's mapping tables as and when someone on that OS is able to consider the situation. I adopted the general principle that it was usually a bad idea to map two distinct error values to the same Rust error code. I notice that this principle is already violated in the case of `EACCES` and `EPERM`, which both map to `PermissionDenied`. I think this was probably a mistake but it would be quite hard to change now, so I don't propose to do anything about that. However, for Windows, there are sometimes different error codes for identical situations. Eg there are WSA* versions of some error codes as well as ERROR_* ones. Also Windows seems to have a great many more erorr codes. I don't know precisely what best practice would be for Windows. ``` <strike> ``` Errno values I wasn't sure about so *haven't* included: EMFILE ENFILE ENOBUFS ENOLCK: These are all fairly Unix-specific resource exhaustion situations. In practice it seemed not very likely to me that anyone would want to handle these differently to `Other`. ENOMEM ERANGE EDOM EOVERFLOW Normally these don't get exposed to the Rust callers I hope. They don't tend to come out of filesystem APIs. EILSEQ Hopefully Rust libraries open files in binary mode and do the converstion in Rust. So Rust code ought not to be exposed to EILSEQ. EIO The range of things that could cause this is troublesome. I found it difficult to describe. I do think it would be useful to add this at some point, because EIO on a filesystem operation is much more serious than most other errors. ENETDOWN I wasn't sure if this was useful or, indeed, if any modern systems use it. ENOEXEC It is not clear to me how a Rust program could respond to this. It seems rather niche. EPROTO ENETRESET ENODATA ENOMSG ENOPROTOOPT ENOSR ENOSTR ETIME ENOTRECOVERABLE EOWNERDEAD EBADMSG EPROTONOSUPPORT EPROTOTYPE EIDRM These are network or STREAMS related errors which I have never in my own Unix programming found the need to do anything with. I think someone who understands these better should be the one to try to find good Rust names and descriptions for them. ENOTTY ENXIO ENODEV EOPNOTSUPP ESRCH EALREADY ECANCELED ECHILD EINPROGRESS These are very hard to get unless you're already doing something very Unix-specific, in which case the raw_os_error interface is probably more suitable than relying on the Rust ErrorKind mapping. EFAULT EBADF These would seem to be the result of application UB. ``` </strike> <i>(omitted errnos are discussed below, especially in https://github.com/rust-lang/rust/pull/79965#issuecomment-810468334) |
||
|---|---|---|
| .. | ||
| benches | ||
| src | ||
| tests | ||
| build.rs | ||
| Cargo.toml | ||