RxJava中参数前置校验的位置选择：方法根还是Completable内部？

这是个非常务实的问题——在RxJava这类响应式框架里，参数校验的位置确实会影响代码的可读性、错误处理逻辑，甚至是资源开销。咱们来拆解两种方案的优缺点，再对应你的场景给出建议：

方案一：在方法最外层检查（Completable.create()之前） #

优点 #

• 快速失败，避免浪费：参数错误（比如path为null）会立刻抛出异常，不会进入RxJava的订阅流程，省去了不必要的对象创建（比如new File(path)）和线程调度开销（如果后续有subscribeOn之类的调度逻辑）。
• 符合常规编码直觉：普通Java方法的参数校验大多放在方法开头，其他开发者一眼就能看到校验规则，维护起来更直观。
• 异常语义清晰：直接抛出NullPointerException（或自定义非法参数异常），能明确传达“参数本身非法”的问题，和流执行过程中出现的IO错误做明显区分。

缺点 #

• 同步异常需要调用方额外捕获：如果你的方法在非阻塞场景下被调用，这个同步抛出的异常可能会跳出响应式流的错误处理链条——不过这类参数错误本质是编程失误，应该在开发阶段就被发现，所以影响不大。

方案二：在Completable的起始位置检查 #

优点 #

• 错误统一由Rx流处理：所有异常都通过emitter.onError()传递，调用方可以完全依赖subscribe()的错误回调来处理，不用额外处理同步异常，保持响应式代码的一致性。
• 适配复杂校验场景：如果参数校验需要依赖异步操作（比如查数据库确认路径合法性），放在流里能和后续逻辑统一编排，更符合响应式编程的思路。

缺点 #

• 延迟失败，冗余开销：哪怕参数是null，也会先进入Rx的创建流程，做一些初始化工作后才抛出错误，有点浪费资源。
• 可读性降低：校验逻辑藏在Completable.create()的lambda里，其他开发者需要深入到流内部才能看到，不如外层校验醒目。
• 异常语义模糊：参数错误抛出的异常会和流执行中出现的IO异常混在一起，调用方需要额外判断异常类型才能区分是参数问题还是实际操作失败。

针对你的场景的建议 #

结合你给出的代码（只是简单的null校验），我完全支持你倾向的方法最外层检查。这是个纯粹的编程错误（传递null路径），应该在方法入口就立刻拦截，既符合常规编码习惯，又能避免不必要的Rx流程开销。

你可以用Java自带的Objects.requireNonNull()简化校验代码，让逻辑更清晰：

public Completable createDirectory(final String path) {
    Objects.requireNonNull(path, "Path cannot be null");
    return Completable.create(emitter -> {
        final File directory = new File(path);
        final boolean createdSuccessfully = directory.mkdirs(); // 注意：Java里是mkdirs()，你代码里的mkDirs()是拼写错误哦
        if (createdSuccessfully) {
            emitter.onComplete();
        } else {
            emitter.onError(new IOException("Failed to create directory."));
        }
    });
}

如果未来你的场景需要异步参数校验，再考虑把校验逻辑移到Rx流里也不迟——但对于这种简单的null校验，外层检查绝对是更优的选择。

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