don’t just wrap std::io::Error like that. same with request::Error. your custom errors are there to tell you about your domain. “there was an IO error” doesn’t mean a lot to your users. you could have wrapped that like AppError::ConfigLoadError or whatever; this is a big reason for having domain errors (or custom errors if you like) in the first place.
thiserror is a great package with great docs that does a lot of this for you.
don’t be afraid to nest your internal module errors. we use ConfigError all way down to something like OurBeskpokeFormatError, for example. then use implFrom<ConfigError> forAppError. this of course depends on the scale of your application, but a 1000 line AppError enum is a mess.
great advice generally! i’ve seen apps start off with anyhow and get stuck there with badly structured errors wedged in everywhere
i have thoughts.
yes, custom errors are great. do them.
don’t just wrap
std::io::Errorlike that. same withrequest::Error. your custom errors are there to tell you about your domain. “there was an IO error” doesn’t mean a lot to your users. you could have wrapped that likeAppError::ConfigLoadErroror whatever; this is a big reason for having domain errors (or custom errors if you like) in the first place.thiserroris a great package with great docs that does a lot of this for you.don’t be afraid to nest your internal module errors. we use
ConfigErrorall way down to something likeOurBeskpokeFormatError, for example. then useimpl From<ConfigError> for AppError. this of course depends on the scale of your application, but a 1000 lineAppErrorenum is a mess.great advice generally! i’ve seen apps start off with
anyhowand get stuck there with badly structured errors wedged in everywhere