Wait, what? Any more details about this, I’ve never heard about that before. Partially run Drop impls sounds like a big potential for undefined behavior, how could catch_unwind possibly cause that?

Yeah, no, I don't think this is true. It's the reason a double panic will cause an abort. The docs do recommend against using this for general error recovery, but there's no mention of any possibillity of inconsistent state.

Depending on a usecase you might find that many of your "entrypoint functions" might all share the same error type. For example, if you're making an API backend it's likely gonna be something a status code and a message.

In that case a simple way to avoid having to pattern match every single error is to implement From<DownstreamErrorType> for MyErrorEnum, and just use the ? operator. Example:

fn do_something_with_database() -> Result<Whatever, DatabaseError> { /* ... */ }

impl From<DatabaseError> for MyErrorType { /* ... */ }

// this would be your function
fn api_get_something() -> Result<SomeOtherType, MyErrorType> {
    let data: Whatever = do_something_with_database()?;
    // ...
    Ok(/* ... */)
}

EDIT: this is mentioned in the article already

I think this is more idiomatic:

let result = foo(a, b)
    .map_err(|e| MyErrorEnum::Error(e.to_string()));

There is the map_err method on Result which simplifies this case. But yes, anyhow is still easier if you don't care that much about the error contents.

That's what ? is for. If you have to do that manually, something is not working correctly.

sorry about that. it's hosted on a free server and they get overloaded from time to time :(