It seems strange to me that (especially in a testing context) there isn't a form of Result::expect or the like that simply stringifies the error and uses that as the panic message.
Have I somehow missed this?
For testing purposes, I may call a function with a set of parameters or input that I know should not fail, and if it does, I want the error printed in the panic message.
While I know I can write a macro to do this, it seems like something fairly reasonable to have as part of Result.
Any thoughts or ideas?
Result::unwrap() doesn't seem to stringify the Err; instead it "{:?}" prints the value.
Yes, the value in Err -- which if it is an Error object instead of a string, causes the "{:?}" representation of the object to be printed instead of the string representation:
---- parser stdout ----
thread 'parser' panicked at 'called `Result::unwrap()` on an `Err` value: Malformed { astr: "file", apos: 4, aerr: "no attributes", afmri: None }', ../src/libcore/result.rs:837
note: Run with `RUST_BACKTRACE=1` for a backtrace.
While I can see why some might prefer the "{:?}" representation of the Err, I'd prefer the fmt::Display representation instead.
Note that I said in the context of testing -- I'm not sure if this oddity is particular to "cargo test".
impl<T, E> Result<T, E> where E: Debug {
fn unwrap(self) -> T {...}
fn expect(self, msg: &str) -> T {...}
}
So these can only use traits within the constraints. It doesn't know that your E actually does implement Display and Error, only Debug. However, this might be something specialization could handle.
Ah, I don't know why I didn't think to check the signature. Thanks.
Do you think that if I suggested a specialization that it would be accepted or would the change in behaviour be sufficiently different that it would be considered too surprising?
I had assume it might and so had thought perhaps another form would be acceptable, such as Result::panic or the like.
Error already implies Display, so you don't need to mention that.
I think you need an additional trait behind the scenes to make specialization work. See how SpecExtend works for extending vectors, for instance. So the signature of the impl Result wouldn't change, but it would use a specialized trait to do different things depending on whether Error is implemented.