我有这段代码。
if let Ok(file) = env::var("CONF") {
if let Ok(mut reader) = fs::File::open(&file) {
if let Ok(conf) = Json::from_reader(&mut reader) {
// do something with conf
}
}
}
我试图让它不像节日假日树,并且正在考虑链接。请注意,此链中的每个步骤都会产生另一个Result
,所以显然这不起作用(我们在Result
中得到Result
。
let conf = env::var("CONF")
.map(fs::File::open)
.map(Json::from_reader);
// do something with conf
此外,我的错误类型因步骤而异,这意味着我无法将.map
替换为.and_then
。
我想我正在寻找类似于JavaScript承诺的东西。也就是说,从承诺内部返回的承诺揭开了内在的承诺。签名可能应该是:
impl<T, E> Result<T, E> {
fn map_unwrap<F, U, D>(&self, op: F) -> Result<U, D>
where F: FnOnce(T) -> Result<U, D>
}
Rust中有这样的机制吗?还有另一种方法可以摆脱我的节日假日树吗?
答案 0 :(得分:8)
Rust中有这样的机制吗?
是的 - 尽管不是像你所呈现的一样。让我们回顾一下你的理论签名:
impl<T, E> Result<T, E> {
fn map_unwrap<F, U, D>(&self, op: F) -> Result<U, D>
where
F: FnOnce(T) -> Result<U, D>,
{}
}
这不起作用 - 假设我们从Err
变体开始 - 此代码如何知道如何从E
转换为D
?此外,&self
不适合想要转换类型的函数;那些通常需要self
。
您需要合并两个组件:
impl<T, E> Result<T, E> {
fn and_then<U, F>(self, op: F) -> Result<U, E>
where
F: FnOnce(T) -> Result<U, E>,
{}
}
impl<T, E> Result<T, E> {
fn map_err<F, O>(self, op: O) -> Result<T, F>
where
O: FnOnce(E) -> F,
{}
}
然后,您将需要一个可以表示两种错误类型的类型。我会懒惰并使用Box<Error>
结合在一起,您需要以下内容:
use std::env;
use std::fs::File;
use std::error::Error;
fn main() {
let conf = env::var("CONF")
.map_err(|e| Box::new(e) as Box<Error>)
.and_then(|f| File::open(f).map_err(|e| Box::new(e) as Box<Error>));
}
现在每次调用都会将错误值转换为共享类型,并且结果可以与and_then
链接。据推测,您的真实代码会创建一个适合您的问题的错误类型,然后您将在map_err
调用中使用它。我implement From
,那你就可以了:
let conf: Result<_, Box<Error>> = env::var("CONF")
.map_err(Into::into)
.and_then(|f| File::open(f).map_err(Into::into));
答案 1 :(得分:4)
如果你真的想忽略与if let
一样的结果,你可以使用这样的宏:
macro_rules! iflet {
([$p:pat = $e:expr] $($rest:tt)*) => {
if let $p = $e {
iflet!($($rest)*);
}
};
($b:block) => {
$b
};
}
fn main() {
iflet!([Ok(file) = env::var("CONF")]
[Ok(mut reader) = File::open(&file)]
[Ok(conf) = Json::from_reader(&mut reader)] {
// do something with conf
});
}
Playground (without Json part)
宏最初来自an answer I made to a similar question on Option
s,但适用于任何if let
。但是,Result
您经常希望以某种方式使用Err
,因此我倾向于the approach explained by Shepmaster或?
/ try!
。