тек-с, как этого бота сраного настраивать

а зачем тебе здесь бот?

я видел слишком много каналов, которых постигла ужасная судьба из-за ёбаных спамеров

в общем я хз будет ли группа пользоваться спросом, если нет, никогда не поздно её заабандонить )

Я правильно понимаю что ничего нового придумывать с ошибками кроме как заюзать failures нету?

ни о чём новом не слышал

failures + derive_more == profit

#[derive(Fail, Debug, From)]
pub enum PasteError {
    /// Input/output error.
    #[fail(display = "{}", _0)]
    Io(#[cause] io::Error),

    #[fail(display = "{}", _0)]
    /// ID decoder error.
    IdDecode(#[cause] base64::DecodeError),

    #[fail(display = "Utf8 error: {}", _0)]
    /// Failed converting into UTF-8 string.
    Utf8(#[cause] str::Utf8Error),

    #[fail(display = "Int parsing failed")]
    /// Failed parsing integer.
    ParseInt(#[cause] num::ParseIntError),
....
}

и автоматом будет работать ? для всех трёх "внутренних" ошибок

незаменимая вещь при обработке ошибок, когда пишешь асинхронщину

у Future (и Stream) есть волшебный метод from_err: https://docs.rs/tokio/0.1.7/tokio/prelude/future/trait.Future.html#method.from_err

так что я обычно в итоге оборачиваю все внутренние ошибки в свою кастомную ошибку и получаю лютый профит )

вместо бесконечных map_err

причём обычно type inference работает так, что указывать дженерик-аргумент нужно либо один раз, либо вообще ноль

Попробую, а то иногда начинаю об эксепленах мечтать.

f1.and_then(f2). f1: кидает ошибки типа E1, a f2: кидает ошибки E2. такая конструкция требует чтобы ошибка была одного типа, хотя по сути то, что кидает f2 меня вообще не интересует.

если тебя не интересует вообще возвращаемый тип всей конструкции, то и мапь всё на ()

так интересует, но только то что кидает f1, чтобы в features_retry хэндлить