PHP MVC框架下异常的使用场景困惑

Question

各路大神，已经从事php开发好几年了，至今还是没有理解好异常使用场景的问题。

以前：

异常感觉是很底层的东西，我这个菜鸟水平还是不要用了，免得闹笑话。后台找到有三个全局的处理开关。

// 设定错误和异常处理
register_shutdown_function('Core::fatalError');
set_error_handler('Core::appError');//trigger_error
set_exception_handler('Core::appException');//throw new

模型层基本上错误都是写日志，控制器层判断调用模型层返回false之后返回相应的错误提示。很简陋吧，没办法一个人干了前后台所有的事情，没时间也没有机会去重构。

现在：

后台业务越来越复杂，两层的基础上增加了一层Logic层，数据校验和业务逻辑都转到Logic层了，这样就增啊Logic与Controller层之间的信息传递，暂且称之为交互吧，现在的交互方式是统一返回一个数组：
return array('ret_code'=>0/1, ret_msg=>'');

最近看了《PHP核心技术与最佳实践》一书中的的1.6章节，发现异常还可以应用到业务逻辑上的判断，激动的不得了，是不是意味着以前模型层的错误是不是也可以通过throw异常来处理错误信息到Logic层，Logic层也可以将数据校验和逻辑判断上的错误throw异常到Controller层。
于是网上找了好多资料，有说不能这样做的，还是要通过错误码来传递，有说可以的，捕获自定义异常处理。也也要说两者结合使用的。但始终没有找到源代码来佐证这些处理方式可以完整的处理层之间的信息传递。
我想知道Model->Logic->Controller怎样处理正常信息与错误信息的传递比较合适？

Answer 1

一般来说，异常情况有两个返回形式，一个通过错误码，另一个就是抛出异常，这两种处理方式在使用上有偏向

• 错误码： 返回错误码属于处理流程的一部分，就是说我知道它发生了错误，而且这错误是预料之内。比如说，Model 查询用户权限，发现用户无权限，然后返回 1 给 Controller
• 异常： 抛出异常一般用于意料之外的问题，不属于处理流程之中的，比如说 Model 查询用户信息，然后莫名连接中断，这就应该抛出异常进行异常处理

然后回到题主这里，异常可以和错误码可以一起使用。数据校验和逻辑判断代码中，如果异常是属于流程的一部分，比如说校验不通过，就返回错误码；如果不属于流程的一部分，比如数据丢失/IO异常/未知问题，就抛出异常。最后针对不同错误进行不同处理。