C#异步调用API方法返回结果或错误的最优实现方案是什么

你当前的实现存在明显缺陷：吞掉了所有异常，调用方完全感知不到调用失败，只会拿到初始的空列表，极易埋下隐性bug。针对「既要返回业务结果也要传递异常信息给调用方」的需求，主流有两种成熟方案，具体如下：

这是这类场景的首选方案，核心是用一个泛型包装类统一承载所有返回信息，包括成功状态、业务数据、错误详情。
首先定义通用的结果包装类：

public class OperationResult<T>
{
    public bool IsSuccess { get; set; }
    public T Data { get; set; }
    public string ErrorMessage { get; set; }
    public Exception Exception { get; set; }

    // 快捷创建成功结果的静态方法
    public static OperationResult<T> Success(T data) => new() { IsSuccess = true, Data = data };
    // 快捷创建失败结果的静态方法
    public static OperationResult<T> Fail(string errorMsg, Exception ex = null) => new() { IsSuccess = false, ErrorMessage = errorMsg, Exception = ex };
}

改造后的GetClients方法实现：

public async Task<OperationResult<List<ClientModel>>> GetClients()
{
    try
    {
        var results = await myHttpClient.GetFromJsonAsync<List<ClientModel>>("Api/Clients");
        // 可根据业务需求补充空值判断逻辑，决定空返回属于成功还是失败场景
        return OperationResult<List<ClientModel>>.Success(results);
    }
    catch (Exception e)
    {
        // 可按异常类型返回更精准的错误信息，比如区分HttpRequestException、JsonException
        return OperationResult<List<ClientModel>>.Fail("获取客户端列表失败", e);
    }
}

调用方使用方式清晰直观，无需额外写try-catch即可判断调用结果：

var clientResult = await GetClients();
if (clientResult.IsSuccess)
{
    var clients = clientResult.Data;
    // 处理正常业务逻辑
}
else
{
    // 处理错误场景，比如弹出提示、记录日志
    _logger.LogError(clientResult.Exception, clientResult.ErrorMessage);
}

优势：语义清晰，调用方可强制处理成功/失败分支，完全适配异步场景，适合错误属于业务预期内的场景

如果API调用失败属于不可预期的程序故障，而非业务预期内的可处理错误，可以选择不吞异常，或者包装为自定义异常后抛出，交给上层调用方通过try-catch处理：

public async Task<List<ClientModel>> GetClients()
{
    try
    {
        return await myHttpClient.GetFromJsonAsync<List<ClientModel>>("Api/Clients");
    }
    catch (Exception e)
    {
        // 可先记录日志再抛出，或者包装为自定义异常后抛出
        _logger.LogError(e, "调用客户端接口失败");
        throw new CustomApplicationException("获取客户端列表失败", e);
    }
}

优势：代码简洁，无需额外定义包装类，符合.NET异常处理的常规设计规范，适合异常属于非预期故障的场景

首先你当前的方法是异步方法，语法层面就不支持使用ref或者out参数，该方案本身就不可行。
就算是同步方法，用ref/out传递错误信息也不属于良好设计，原因包括：

• 可读性极差，方法返回值仅承载数据，错误信息靠额外参数传递，不符合常规的方法语义
• 调用方必须提前声明变量接收out/ref参数，使用繁琐
• 无法适配异步、链式调用、函数式编程等场景，扩展性极差
• 没有统一的错误处理规范，团队协作容易出现风格混乱的问题

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