Комментарии 6
))))))))))))))))))))))))
Ну как-то так.... Прекрасный пересказ вводной статьи из руководства по Rust. А каким-же все-таки идиоматическим способом обрабатывать ошибки в реальном софте, в котором 40 зависимостей, каждая со своим набором ошибок, обмазано все асинхронностью, хотя бы с помощью Tokyo, и все это затолкано в собственные крейты для удобства администрирования и декомпозиции, не рассказано. За перевод - спасибо, притарю статью в закладки.
Я тоже зашёл поучиться как это должно быть и не нашел ответа. Я читал что есть 2 подхода энихау и зисэрор. Иделмптически энихау применяется в конечных приложениях, а зисэрор в библиотеках. У меня технически библиотека, длл, но по факту это миниприложение, плагин, в котором уже много бизнес логики и будет ещё больше. Я делаю так, у меня есть мой тип ошибки, что типа наивный энихау, но у меня 3 категории ошибок к которым я свожу все ошибки зависимостей. Я бы взял как раз энихау, но мне нужно 3 категории, а у него только 1. Мои категории это внутренняя логическая ошибка плагина - баг плагина, ошибка на стороне хоста не валидный ввод/прекандишен ваолэйшен - баг на стороне хоста/придожения, и ошибка среды/системная/рантайм, в общем все остальное, что не папало в первые 2 категории - не баг, а просто так звёзды сложились.
И все у меня в общем то хорошо получается, я в ручную доптсываю фром для новых ошибок когда надо, довольно редко, а дальше будет ещё реже.
Но есть одна проблема, которая меня беспокоит, но как ее решить я пока не знаю - у меня есть служебный/библиотечный крэйт который потенциально можно заопенсорсить и как раз в нем находиться определение моей ошибки, а бизнес логика живёт в другом крэйте. Проблема в том что при добавлении зависимости в бизнес крэйт мне приходиться ее также добавить и в служебный, что бы я мог написать реализацию фром трэйта для новой ошибки. Других причин для добавления зависимости в служебный крэйт нет и это напрягает.
Идеально было бы реализовать фром из одной ошибки в другую в бизнес крэйте, но это не возможно т.к. обе ошибки и конечно же сам трэйт внешние по отношению к бизнес крэйту.
`#[from]` Это, конечно, здорово, для простейших ошибок или туториалов вроде этого, но есть маленькая проблема в практическом применении. from()/into() не работают когда нужно добавить какие-то доп поля в ошибку.
A
Fromimpl is generated for each variant containing a#[from]attribute.Note that the variant must not contain any other fields beyond the source error and possibly a backtrace. A backtrace is captured from within the
Fromimpl if there is a field for it.
Вот, например, гипотетический вариант: мы хотим сделать upload директории рекурсивно (в не download в temp file), в какой-то момент этот процесс выдает ошибку и мы ее открываем и видим там Error::File(std::io::Error), даже можем достать ErorrKind из нее который нам скажет PermissionDenied... А для какого файла? В IoError по дизайну эта инфа не записывается, а в месте вызова нашей чудо функции у нас есть только путь к директории внутри которой зловредный файл расположен...
А для такого простого варианта где нам нужно вернуть несколько возможных значений из функции внутри нашего приложения (а не, анпример, из публичного API библиотеки) - тут и простой enum без this_error макро подойдет. Да и, на самом деле, в anyhow можно сделать downcast ошибки чтобы получить типизированную внутреннюю ошибку, что может быть жестью в либе, а в конкретном одном месте своего собственного приложения - вполне норм
Да, это действительно проблема.
Поэтому anyhow и thiserror так мне никогда и не пригодились. В простейших случаях проще и нагляднее вручную все реализовать. В сложных ситуациях эти крейты и так бесполезны.
Хотя конечно при ручной реализации надо ошибки выносить в отдельный файл, п то быстро запутаться можно
А у кого нибудь скомпилировался хоть один пример не считая первых 2х? Просто я открыл РастРовер установил последнюю версию раста. пофиксил ошибку с линтером а дальше все. Надо гуглить/править/искать ошибки. эмммм.... Норм статья для новичков) спасибо
Идиоматическая обработка ошибок в Rust