A
thiserror, snafu
В телохиде что?
Size: a a a
2020 April 18
G
thiserror
ID
Я вот буквально час назад расписывал внутреннее письмо почему нам надо на thiserror + anyhow переходить 😅
ID
Краткое содержание: failure::Fail фу; std::error::Error наше все. failure::Fail в итоге раскололо экосистему, dyn Fail несовместим с dyn Error; поэтому, чем быстрее failure будет выжжен, тем лучше.
G
Привет! Можно посоветоваться по организации архитектуры библиотеки с фьючерсами?
Задача такая. Есть некий объект Factory, который создает некие экзампляры Instance, связанные с Factory. Инстансы создаются асинхронно. При этом инстансы связаны с Factory(используют некоторый стафф из них по ссылкам), и обычно имеют ограниченное время жизни. Также инстансы имеют асинхронные методы, для выполнения некой важной работы.
Мне нужно организовать архитектуру так, чтобы пользователь мог создавать свои собственные имплементации и Factory, и Instance. Кроме того, у обеих сущностей есть некое дефолтное поведение.
У меня что-то такое получилось, организовав Factory и Instance в виде трейтов с лайфтайм-ссылками, ассоциированными типами, и навесив на все это async_trait(а местами выведя дефолтные методы отдельно от трейтов, так как async_trait не справился с резолвом лайвтайм-границ как надо). Но это все получилось очень-очень громоздко. Как это можно сделать менее громоздко?
Задача такая. Есть некий объект Factory, который создает некие экзампляры Instance, связанные с Factory. Инстансы создаются асинхронно. При этом инстансы связаны с Factory(используют некоторый стафф из них по ссылкам), и обычно имеют ограниченное время жизни. Также инстансы имеют асинхронные методы, для выполнения некой важной работы.
Мне нужно организовать архитектуру так, чтобы пользователь мог создавать свои собственные имплементации и Factory, и Instance. Кроме того, у обеих сущностей есть некое дефолтное поведение.
У меня что-то такое получилось, организовав Factory и Instance в виде трейтов с лайфтайм-ссылками, ассоциированными типами, и навесив на все это async_trait(а местами выведя дефолтные методы отдельно от трейтов, так как async_trait не справился с резолвом лайвтайм-границ как надо). Но это все получилось очень-очень громоздко. Как это можно сделать менее громоздко?
BoxFuture и вперёд, async-trait лишь усложняет поддержку кода
K
Краткое содержание: failure::Fail фу; std::error::Error наше все. failure::Fail в итоге раскололо экосистему, dyn Fail несовместим с dyn Error; поэтому, чем быстрее failure будет выжжен, тем лучше.
ID
Да, только цепочки-то не работают.
A
То есть если хотим строгости thiserror. А если хотим просто по быстрому, то anyhow?
K
а я напомню, что snafu, anyhow & thiserror в отличии от фейлуры не поддерживают no_std
ID
std::error::Error::source возвращает &dyn std::error:🧼Error
K
То есть если хотим строгости thiserror. А если хотим просто по быстрому, то anyhow?
thiserror + anyhow обычно в связке, это быстро и без заморочек
если структурировано то snafu
если структурировано то snafu
A
thiserror + anyhow обычно в связке, это быстро и без заморочек
если структурировано то snafu
если структурировано то snafu
Я не понимаю как связывать их.
A
Одно без типа, просто еррор с мессагой
ID
Поэтому
Fail::compat(fail).source() вернет None.A
Другое конкретный тип
K
ну thiserror дает derive(Error), anyhow дает возможность работы с std::error::Error (bail, context, etc)
ID
Ну, у нас наверху, в приложениее —
failure::Error (аналог anyhow::Error`). Внизу, в библиотеках, `derive(Fail) (аналог `thiserror::Error`).ID
snafu смотрел, че-то не поперло. По-моему, недостаточно навороченный контекст у него был...ID
Поэтому ручками через
.map_err() делаем.