JavaScript自定义异常适用场景与两种定义方案优劣对比

你提到的两种自定义错误方案在JavaScript中都是完全合法可行的，二者都保留了原生Error实例的堆栈信息、instanceof Error校验能力，远好于直接抛出普通对象/字符串的做法。

方案1：Object.assign改造原生Error对象 #

优点 #

• 实现成本极低，不需要提前定义类结构，临时、少量使用时代码非常精简
• 没有语法兼容性负担，不支持class语法的老旧环境也可以正常使用
• 灵活度极高，可随时附加任意自定义字段，无需提前预设结构

缺点 #

• 没有统一构造逻辑，多次使用时极易出现字段命名不一致、结构混乱的问题，维护成本随使用次数上升快速升高
• 无法通过instanceof做精细化错误类型判断，只能依赖name/code字段值判断，分支判断逻辑繁琐且容易出错
• 无法扩展自定义方法，比如统一实现错误序列化、获取重试策略等业务逻辑都做不到

方案2：继承Error的自定义错误类 #

优点 #

• 错误类型判断便捷，直接用instanceof 自定义类名即可快速区分错误类别，catch分支逻辑清晰易维护
• 同类型错误的结构完全统一，构造函数参数约束可以从根源避免字段写错、漏传的问题
• 支持扩展自定义属性和方法，比如统一预设错误前缀、实现序列化方法、附加错误上报逻辑等
• 符合整洁架构的设计思路，错误类型和业务领域/服务分层对应，代码可读性更高

缺点 #

• 需要提前定义类结构，单次少量使用时代码量高于方案1
• 如果强行给所有细分场景都定义独立错误类，确实会产生无意义的冗余代码，增加维护负担

是不是必须给所有领域/服务都定义单独的自定义错误类？ #

不需要。你完全可以先定义几个通用的大分类错误类，比如基础的BaseCustomError、业务服务层通用的ServiceError、参数校验类的ValidationError、领域逻辑层通用的DomainError，具体错误场景通过code字段区分即可，兼顾结构一致性和代码精简度，不需要为了所谓的代码对称性硬造大量只用一次的错误类。

直接抛出普通对象是不是反模式？ #

是标准的反模式。这种做法会丢失原生Error自带的堆栈追踪信息，排查问题时完全无法定位错误抛出的位置；也无法通过instanceof Error做通用错误捕获，全局异常监听、错误上报等通用逻辑都会失效，极易导致异常漏处理、日志无有效信息的问题，完全不推荐使用。

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