Rust+async-graphql全局错误处理与自定义公开错误信息咨询

问题1：避免每个解析器重复编写.map_err() #

有两种简洁的解决方案：

方案1：使用全局错误钩子 #

async-graphql 的 SchemaBuilder 提供全局错误回调，可统一捕获所有解析器的错误并处理日志，无需修改每个解析器的代码：

use async_graphql::{Schema, EmptySubscription};
use tracing::error;

// 构建Schema时设置全局错误处理
let schema = Schema::build(QueryRoot, MutationRoot, EmptySubscription)
    .on_error(|err| {
        // 打印完整错误链日志
        error!("{:?}", err);
    })
    .finish();

此时解析器可直接使用?操作符，因为anyhow::Error会自动转换为async_graphql::Error，全局钩子会自动处理日志：

#[Object]
impl MutationRoot {
    async fn player_create(&self, ctx: &Context<'_>, input: PlayerInput) -> Result<Player> {
        let services = ctx.data_unchecked::<Services>();
        // 直接用?，无需手动map_err
        let player = services.player_create(input).await?;
        Ok(player)
    }
}

方案2：自定义应用错误类型 #

如果需要更精细的错误控制，可定义自己的错误类型，实现From<anyhow::Error>和Into<async_graphql::Error>，在转换逻辑中嵌入日志：

use thiserror::Error;
use async_graphql::Error as GraphQLError;
use tracing::error;

#[derive(Error, Debug)]
enum AppError {
    #[error("业务错误: {0}")]
    DomainError(DomainError),
    #[error("外部服务错误")]
    ExternalError(#[from] anyhow::Error),
    // 其他自定义错误类型...
}

// 自动将anyhow::Error转换为AppError
impl From<anyhow::Error> for AppError {
    fn from(err: anyhow::Error) -> Self {
        error!("{:?}", err);
        AppError::ExternalError(err)
    }
}

// 自动将AppError转换为GraphQL错误
impl Into<GraphQLError> for AppError {
    fn into(self) -> GraphQLError {
        GraphQLError::new(self.to_string())
            // 可添加扩展字段，比如错误码
            .extend_with(|_, e| e.set("code", self.code()))
    }
}

// 解析器返回Result<T, AppError>
#[Object]
impl MutationRoot {
    async fn player_create(&self, ctx: &Context<'_>, input: PlayerInput) -> Result<Player, AppError> {
        let services = ctx.data_unchecked::<Services>();
        let player = services.player_create(input).await?;
        Ok(player)
    }
}

问题2：提取错误链中特定层级的错误信息 #

anyhow的错误链可通过chain()方法遍历，你可以根据错误类型或内容筛选出目标错误，替换默认返回的最上层错误：

示例：按错误类型提取 #

假设你的错误链中有自定义的DomainError类型，需要返回该类型的错误信息：

use tracing::error;
use async_graphql::Error as GraphQLError;

fn errorify(err: anyhow::Error) -> GraphQLError {
    error!("{:?}", err);

    // 遍历错误链，找到第一个DomainError
    let target_err = err.chain()
        .find(|e| e.downcast_ref::<DomainError>().is_some())
        // 如果找不到则 fallback 到原错误
        .unwrap_or(&err);

    // 用目标错误的信息构建GraphQL响应
    GraphQLError::new(target_err.to_string())
        .extend_with(|_, e| {
            if let Some(domain_err) = target_err.downcast_ref::<DomainError>() {
                e.set("code", domain_err.code());
            }
        })
}

注意：优先用类型筛选而非字符串 #

尽量避免通过错误消息字符串匹配，因为字符串易变且不可靠。定义明确的错误类型（用thiserror）是更健壮的方案。

Rust 错误链实现与 anyhow 的替代方案 #

错误链的实现方式 #

在Rust中实现带上下文的错误链，无需依赖anyhow，用thiserror即可：

use thiserror::Error;
use std::error::Error;

#[derive(Error, Debug)]
enum DomainError {
    #[error("玩家已存在: {0}")]
    PlayerExists(String),
    #[error("玩家ID无效: {0}")]
    InvalidPlayerId(u64),
}

#[derive(Error, Debug)]
enum DbError {
    #[error("数据库连接失败")]
    ConnectionFailed,
    #[error("查询错误: {0}")]
    QueryError(String),
}

#[derive(Error, Debug)]
enum AppError {
    #[error("业务逻辑错误: {0}")]
    Domain(#[from] DomainError),
    #[error("数据库错误: {0}")]
    Database(#[from] DbError),
    #[error("IO错误: {0}")]
    Io(#[from] std::io::Error),
}

// 遍历错误链示例
fn print_error_chain(err: &impl Error) {
    eprintln!("错误: {}", err);
    let mut current_err = err.source();
    while let Some(e) = current_err {
        eprintln!("原因: {}", e);
        current_err = e.source();
    }
}

thiserror会自动为每个错误实现Error trait的source()方法，从而形成链式结构。

是否必须用 anyhow？ #

不是。anyhow适合快速开发、不需要严格区分错误类型的场景；而thiserror更适合大型项目，能定义强类型错误，便于精准处理不同错误场景。两者也可以结合使用：用thiserror定义应用核心错误，用anyhow处理外部依赖的不确定错误。

应用级错误处理核心要点 #

1. 强类型优先：用thiserror定义明确的错误类型，避免模糊的Box<dyn Error>
2. 错误链清晰：通过#[from]自动嵌套错误，保留完整上下文
3. 统一处理：在框架层面（如async-graphql的全局钩子）统一处理日志和错误响应
4. 避免字符串匹配：始终通过错误类型判断，而非错误消息内容

内容的提问来源于stack exchange，提问作者Fred Hors