从调用方控制服务执行流程是否属于良好实践？

首先得说，你这种通过throwException布尔参数来控制服务方法是否抛异常的写法，能实现功能，但绝对不是推荐的良好实践，咱们来拆解下问题，再看看更优的方案：

为什么这种写法有问题？ #

• 违反单一职责原则：你的Foo方法现在既要负责核心业务逻辑（计算result），又要处理“是否抛出异常”的流程控制，一个方法承担了两个不同的职责，后续维护起来很容易混乱。
• 可读性差，语义模糊：光看方法签名Foo(int? number, bool throwException)，你得额外去看方法内部逻辑才能明白这个布尔参数到底控制什么。如果后续需要更多异常相关的控制（比如不同错误类型、自定义错误信息），你可能还要加更多参数，最终方法签名会变得臃肿不堪。
• 误用异常的设计初衷：异常是用来处理意外的、不可恢复的错误场景，而不是作为普通的流程控制手段。用参数开关来决定抛不抛异常，相当于把异常当成了可选的返回路径，这违背了异常的设计本意。

你原本想避免的写法，其实更合理？ #

你提到的那种“调用方拿到结果后自己判断抛异常”的写法，虽然看起来代码多了几行，但职责划分更清晰：服务类的方法只负责返回计算结果，调用方根据自身业务需求决定如何处理结果（抛异常、降级处理等）。这种“关注点分离”的设计，反而让代码更易读、易维护。

更优的替代方案：拆分方法 #

既然有两种不同的调用需求（需要抛异常/不需要抛异常），不如直接把服务类的方法拆成两个语义明确的方法，让调用方一目了然：

示例代码 #

public class Service {
    // 核心业务逻辑抽成私有方法，避免重复代码
    private int? GetFooCore(int? number) {
        int? result = number;
        if (result == null) {
            // 这里写你的核心计算逻辑
            result = ...;
        }
        return result;
    }

    // 明确表示：如果结果为空则抛出异常
    public int FooOrThrow(int? number) {
        var result = GetFooCore(number);
        if (result == null) {
            throw new Exception("ZZZZ");
        }
        return result.Value;
    }

    // 明确表示：返回结果，为空则返回null（不抛异常）
    public int? FooOrDefault(int? number) {
        return GetFooCore(number);
    }
}

调用方的代码也会更简洁清晰：

public class Caller {
    public void Test1() {
        // 明确知道调用这个方法会在异常场景抛错
        var a = Service.FooOrThrow(number);
        // 后续逻辑
    }
    public void Test2() {
        // 明确知道这个方法不会抛错，需要自己处理null的情况
        var b = Service.FooOrDefault(number);
        // 后续逻辑
    }
}

总结 #

这种拆分方法的方式，既遵循了单一职责原则，又让代码语义清晰，调用方不用再通过模糊的布尔参数来控制服务行为。长远来看，这种设计会让你的代码更易于维护和扩展。

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