std::env::VarError should capture name #22122
Comments
|
cc @aturon |
|
Nominating for 1.0-beta P-backcompat-libs. |
|
1.0-beta P-backcompat-libs |
Now that the `std::env` module has had some time to bake this commit marks most
of its APIs as `#[stable]`. Some notable APIs that are **not** stable (and still
use the same `env` feature gate) are:
* `{set,get}_exit_status` - there are still questions about whether this is the
right interface for setting/getting the exit status of a process.
* `page_size` - this may change location in the future or perhaps name as well.
This also effectively closes rust-lang#22122 as the variants of `VarError` are
`#[stable]` now. (this is done intentionally)
Now that the `std::env` module has had some time to bake this commit marks most
of its APIs as `#[stable]`. Some notable APIs that are **not** stable (and still
use the same `env` feature gate) are:
* `{set,get}_exit_status` - there are still questions about whether this is the
right interface for setting/getting the exit status of a process.
* `page_size` - this may change location in the future or perhaps name as well.
This also effectively closes rust-lang#22122 as the variants of `VarError` are
`#[stable]` now. (this is done intentionally)
|
Can someone explain why this was closed without changing the behaviour? Or am I missing something? |
|
@maximih some more details are in #22869, but the decision was that these sorts of detailed errors are not necessarily in the domain of the standard library. There is a cost overhead for capturing this sort of information which is not necessarily desired by all consumers of the API, so it's up to libraries to provide the extra contextual information where necessary. |
|
I understand that not all consumers require that the environment variable name be captured. However, by not providing a simple method to identify the environment variable in error, I suspect many application administrators will be subjected errors missing this critical piece of information (because deadlines force compromises). I was really hoping this would make it into v1.0 because adding the name is likely to be a breaking change for consumers of VarError. Anyway, if it does not make v1.0, consumers will need to capture the environment variable name if it is needed. Here is my solution: https://gist.github.com/galsondor/d1aadf821300f982ac1f BTW, the "NotUnicode" enum variant captures the error data, which is also not required by all consumers and probably even less useful than the name. |
|
FWIW, #22949 talks more generally about the issue of forward-compatibility with situations like this. I think we should make the |
I have been refactoring command-line program code to use the patterns implied by Improved Error Handling in Rust. Errors are bubbled up to
main()using thestd::error::Errorandstd::error::FromErrortraits. This allows most user messaging to occur in a central location (especially panic-level failures), simplifying testing and internationalization.One issue I have encountered has to do with missing environment variables.
std::env::VarErrordoes not capture the the environment variable name (which std::env calls a key); therefore, the messages fromError::description()andDisplay::fmt()do not tell the user which environment variable is missing. To work around this issue, I have wrappedVarErrorin another struct. It would be much simpler ifVarErrorcaptured the environment variable name and included it in the messages.I realize this is likely to require heap allocation to save a copy of the name. In most (sane) cases, environment variables are accessed once during program initialization and the value stored for future use. Therefore, I believe the benefit of knowing which environment variable is missing outweighs the heap allocation cost.
The text was updated successfully, but these errors were encountered: