在Laravel及通用开发场景中，非控制器/请求类抛出异常是否可行？

当然可以在Repository、Helper这类处理业务或数据逻辑的类中抛出异常，这不仅可行，反而更符合编程原则，下面具体说明：

为什么应该在这类类中抛异常？ #

• 符合单一职责原则：控制器的核心职责是处理请求接收、逻辑调度和响应返回，把异常处理和业务逻辑绑定在控制器里，会让控制器代码臃肿、职责混乱。Repository类本身负责数据操作与业务逻辑封装，它最清楚操作中的异常场景（比如数据不存在、约束冲突、权限不足等），在这里抛出语义明确的异常是职责内的事。
• 逻辑更清晰，复用性更强：在Repository中抛出异常，上层（比如控制器、命令行脚本）只需要捕获对应异常并做响应处理即可，不用重复编写判断逻辑。比如UserRepository::findById($id)找不到用户时，直接抛出UserNotFoundException，而不是返回null让每个调用处都写if (!$user) { ... }。
• 异常语义更精准：自定义业务异常（比如InsufficientStockException、DuplicateRecordException）能清晰传递错误场景，上层可以根据不同异常类型返回不同的响应（比如404、409、403），比通用异常更利于维护。

注意事项 #

• 尽量抛出自定义业务异常，避免直接抛出通用的Exception类，这样上层可以精准区分异常类型，做针对性处理。
• 可以通过全局异常处理器（比如Laravel中的Handler.php）统一处理部分通用异常，减少控制器中的重复捕获代码，但这和在Repository中抛异常并不冲突，反而能形成"底层抛异常，上层/全局统一处理"的清晰流程。

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