Repository navigation
std::env::VarError should capture name #22122
Description
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 the std::error::Error and std::error::FromError traits. 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::VarError does not capture the the environment variable name (which std::env calls a key); therefore, the messages from Error::description() and Display::fmt() do not tell the user which environment variable is missing. To work around this issue, I have wrapped VarError in another struct. It would be much simpler if VarError captured 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.
Activity
alexcrichton commentedon Feb 9, 2015
cc @aturon
aturon commentedon Feb 16, 2015
Nominating for 1.0-beta P-backcompat-libs.
pnkfelix commentedon Feb 19, 2015
1.0-beta P-backcompat-libs
Rollup merge of rust-lang#22869 - alexcrichton:stabilize-env, r=aturon
mhristache commentedon Mar 2, 2015
Can someone explain why this was closed without changing the behaviour? Or am I missing something?
Thanks
alexcrichton commentedon Mar 2, 2015
@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.
scott-ainsworth commentedon Mar 2, 2015
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.
aturon commentedon Mar 3, 2015
FWIW, #22949 talks more generally about the issue of forward-compatibility with situations like this. I think we should make the
enumvariants opaque to allow expansion with more information in the future.Merge pull request rust-lang#22122 from Wilfred/proc_macro_working_dir