dtolnay / dtolnay/thiserror

[Feature request] Enabling support for transitive "#[from]' handling

Open
#435 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
5.5k
Forks
213
PR merge metrics
No merged PRs in 30d

Description

I will explain myself with a very simple example :

Say I have this huge error type on my codebase :

```rust
#[derive(Error, Debug)]
pub enum MyError {
#[error("Network error: {0}")]
Network(String),

#[error("Conversion Error: {0}")]
ConversionError(#[from] ConversionDbError),

// Around 30 other variants
```

And with
```rust

#[derive(Error, Debug)]
pub enum ConversionDbError {
#[error("UUID conversion error: {0}")]
Uuid(#[from] uuid::Error),

#[error("UTF-8 conversion error: {0}")]
FromUtf8(#[from] std::string::FromUtf8Error),

#[error("TryFromIntError conversion error: {0}")]
TryFromInt(#[from] std::num::TryFromIntError),
}
```

I still need to add the manual conversions in order to forward the error down my enum :
```rust
impl From for DbError {
fn from(e: uuid::Error) -> Self {
Self::ConversionError(ConversionDbError::Uuid(e))
}
}
// and the 2 others
```

This kindof takes away my goal from importing the `thiserror` crate, which is to reduce boilerplate redundant code to the maximum. Of course, the code above isn't my production code. My code is so huge that this kind of feature will make it way more human-friendly.

Am I doing smth wrong or this is a feature that can be implemented ?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.