Should config::get panic on configuration error or return Result ?

[mehcode]

@nugend definitely possible and something I'd probably use.

[dependencies]
config = { version = "0.3.1" features = ["panic"] } 

[dtolnay]

Careful - compile-time cfgs are required to be purely additive so you cannot do:

#[cfg(not(feature = "panic"))]
pub fn get<'a>(key: &str) -> Option<&'a Value>

#[cfg(feature = "panic")]
pub fn get<'a>(key: &str) -> &'a Value

This is not purely additive because it removes the function with the first signature. Imagine if my crate A uses config without the panic feature, so it calls config::get().unwrap(). Then I add a dependency on a crate B which uses config with the panic feature. When Cargo resolves the features in my dependency graph, it will build my crate A against config with the panic feature enabled and fail because unwrap() is not a method on &'a Value.

[mehcode]

You're completely right. Let's change this issue then into a .. what does the community want as the method signature?

pub fn get<'a>(key: &str) -> Result<&'a Value, ConfigError>

Or

pub fn get<'a>(key: &str) -> &'a Value

[dtolnay]

Personally I would want:

pub fn get<T: Deserialize>(key: &str) -> Result<T, Error>

and for my use cases, I never see myself ever using any of the other possible signatures.

• get(&str) -> &Value - I would never want to panic because of an unset config value
• get(&str) -> Option<&Value> - if I am using a config library, the library better handle error messages for me at least as well as serde does, otherwise I would use serde directly, cc Deeper integration with Serde #13
• get(&str) -> Result<&Value, Error> - meh, if I wanted this I would use get::<Value> but it would be extremely rare

[mehcode]

@dtolnay Perhaps you can settle an internal dilemma. Do people care about allocation when using a config library?

Eg..

pub fn get_str(key: &str) -> Result<String, Error>

Or

pub fn get_str<'a>(key: &str) -> Result<&'a str, Error>

The main reason for the Unsafe #9 and other weirdness is I have it stuck in my head that this matters and we should try to return a reference if possible.

[dtolnay]

I am sure nobody cares about an allocation. If you need to use a config value inside a hot loop, you load it outside the loop and refer to it from inside the loop. Even with the current reference-based API you would never want to call get inside of a hot loop because it will be slower than calling it once up front.

[mehcode]

@dtolnay That settles that. Thank you for all your help so far.

[tmccombs]

I would also prefer get returning a Result. If the client wants to panic if config is missing, they can always use a .unwrap()

[nugend]

I was actually expecting the signature to just be Result, but that a panic would occur if the feature flag was set (because some applications wouldn't have a sensible way of handling an absent config).

Though I guess just unwrapping would make sense! Sorry, I didn't think it completely through when I mentioned the idea.

[mehcode]

@nugend

Yeah. my_config.get("...").unwrap() or my_config.get("...")? will work nicely.

Going to close this as we seem to all agree.