Ещё об обработке ошибок в Rust

[swizard]

С обработкой ошибок в Rust надо явно что-то придумывать. Мне категорически нравится, что в языке нет исключений, но без синтаксического сахара вроде хаскелевской конструкции do код с аккуратной обработкой ошибок визуально превращается в простыню с перекладыванием значений из одних типов в другие

Comments

[swizard]

Да, try! по-сути делает ровно то же самое, плюс некоторая мелкая магия по автопреобразованию типа ошибки к тому, который требуется сигнатурой.

Это хорошо работает, но только в случае линейного кода. Например, вместо такого:

for value in values.split(',') {
match value.parse() {
Ok(v) =>
result.push(v),
Err(e) =>
return Err(ParamError::SampleValue(value.to_owned(), e)),
}
}
После некоторой подготовки можно написать так:

for value in values.split(',') {
result.push(try!(value.parse()))
}
Но try! теряет полезность в замыканиях, потому что возвращает управление только из анонимной функции, а не из родительской (в КЛ, например, для этого есть return-from, которым можно вернуть управление из любого уровня вложенности).

Например, вот так можно собрать в массив длины всех строк, поданных на stdin:

let stdin = io::stdin();
let all_lines: Vec = stdin
.lock()
.lines()
.map(|line| line.unwrap().len())
.collect();
Map принимает замыкание, в которое lines передаёт Result. Этот result внутри map уже нельзя так просто обработать через try!, потому что управление будет возвращено только из замыкания, но не из родительской функции.

А вот в хаскеле это всё можно делать через аппликативные функторы, например, если я всё правильно понимаю.

[antilamer]

Да, понял, о чем ты. Сам с такой необходимостью не сталкивался, но согласен, что тут на макросах далеко не уедешь. С другой стороны, можно заявить, что это забота функции map, т.е. что надо предоставить overload "map с возможностью ошибки" с хорошо задокументированной семантикой обработки оных ошибок. С аппликативными функторами, правда, можно было бы обойтись и без этого :)