раз читал книги с перерывом в пять лет.
При изучении tokio на «официальном» Tutorial есть такой пример, https://tokio.rs/tokio/tutorial/hello-tokio#write-the-code Когда я дошёл до реализации Shared state, и получения сохранённого в Db значения, я захотел переписать этот прмер с разными инстансами client'а, в простейшем случае так https://gist.github.com/rust-play/f95d0b83086cd97d0d6087950164f401 (создавать новые соединения не следует, но для проверочного примера пойдёт).
Я захотел выделить функции set и get в этом примере. set тривиально (включено в пример ниже). Хотя уже тут вроде бы незачем возвращать Result<()>, но удобно возвращать с "?".
У меня не получалось написать get, но сейчас по-аналогии с set, которая возвращает Result<...>, тоже вернул Result, и оно собралось. Получилось после того, как перестал пытаться вернуть Option<Bytes>: https://gist.github.com/rust-play/2bc6906a69693398672e08edbc48ab09
Попытаться вернуть Option<Bytes>
match result {
Ok(result) => return result,
_ => None
}
не работает из-за main, которая возвращает Result<()>.
Отсюда вопрос: это нормально возвращать Result-ы всю дорогу?
Я правильно понимаю, что - Result на Option - это как в моём втором примере (который не сработтал)? Это сработает, если вызывающая ожидает Option. - Наоборот, - это если получил Option, а выше ожидается Result? Ну и вцелом это такой шаблон с использованием вырианитов.
Угу, там ещё есть ok_or метод на опшене, чтобы матч не писать
Обсуждают сегодня