SQL Server存储过程已处理异常时 EF Core调用是否还需使用try catch

存储过程内置异常处理后，C#端是否还会抛出异常 #

分两种情况：

• 如果存储过程的TRY...CATCH逻辑已经完整捕获所有SQL执行异常，且没有通过THROW、RAISERROR抛出严重级别≥16的错误，那么仅存储过程执行本身不会触发C#侧的异常
• 但如果出现存储过程运行前就会发生的错误，比如数据库连接超时、网络中断、账号权限不足、EF Core参数映射错误等，这部分错误存储过程完全没有机会处理，C#侧必然会抛出异常

是否需要用try catch包裹调用代码 #

建议必须添加，核心原因如下：

• 兜底捕获存储过程覆盖不到的异常：存储过程只能处理SQL运行时的业务异常，连接、网络、权限、EF映射等层面的异常都需要C#侧处理，没有try catch会直接触发服务未处理异常，默认返回500错误，不符合RESTful API的错误响应规范
• 可以统一做错误日志和业务包装：即便存储过程处理了异常，通常也会返回自定义错误码、错误信息作为输出参数或返回值，你可以在try块中判断返回结果做业务处理，catch块中统一记录错误日志、包装成API约定的标准错误格式
• 如果你已经在ASP.NET Core中配置了全局异常中间件做统一兜底，也可以选择不加局部try catch，但前提是你能确保全局中间件可以正确识别所有存储过程调用相关的异常、转化为符合要求的响应

EF Core调用带异常处理的存储过程示例代码 #

public async Task<ApiResult> ExecYourProcAsync(int inputParam, CancellationToken cancellationToken)
{
    try
    {
        // 定义存储过程输出参数，接收存储过程内部处理后的自定义错误信息
        var errOutput = new SqlParameter("@ErrInfo", SqlDbType.NVarChar, 200)
        {
            Direction = ParameterDirection.Output
        };
        // EF Core调用存储过程
        await _context.Database.ExecuteSqlInterpolatedAsync(
            $"EXEC dbo.YourCustomProc @Input={inputParam}, @ErrInfo={errOutput} OUT",
            cancellationToken);
        // 处理存储过程返回的自定义业务错误
        if (errOutput.Value != DBNull.Value)
        {
            return ApiResult.Fail(errOutput.Value.ToString());
        }
        return ApiResult.Success();
    }
    catch (SqlException sqlEx)
    {
        // 处理SQL层面未被存储过程捕获的异常
        _logger.LogError(sqlEx, "调用存储过程dbo.YourCustomProc发生SQL错误");
        return ApiResult.Fail("数据库操作失败，请稍后重试");
    }
    catch (Exception ex)
    {
        // 处理其他EF、连接层面的异常
        _logger.LogError(ex, "调用存储过程dbo.YourCustomProc发生未知错误");
        return ApiResult.Fail("系统内部错误");
    }
}

内容的提问来源于stack exchange，提问作者Antonio De La Garza