由于业务逻辑错误而离开功能的最佳实践答案

【问题标题】：Best practice for leaving a function due to business logic errors由于业务逻辑错误而离开功能的最佳实践
【发布时间】：2012-08-13 15:39:05
【问题描述】：

我只是在寻找一些最佳实践建议。

我有一项服务，“价格表服务”，用户可以在其中保存某种价格表。

有一些实例或配置可能会留下不一致的数据，在这些情况下我想结束函数执行。

例如，如果对象上没有设置 customerId，或者在数据库中找不到销售人员的 userId。

我的问题是当您遇到业务逻辑错误时离开函数的最佳方法是什么？

我喜欢异常停止执行并允许您重新抛出异常的方式。问题是，我听说异常不能用于流量控制。

目前我只有一堆嵌套的 if/else，除非没有设置 $service_error_message 的局部变量，否则我不会提交我的事务。

如果$service_error_message 为空，那么我知道我的验证器都没有失败，可以保存。

有人对如何更好地处理这些情况有建议吗？

【问题讨论】：

如果可能发生的问题是程序正常执行的一部分，我不会使用异常或die之类的东西，您只需要测试有效输入并显示错误消息用户。
@Leigh 感谢 Leigh 的可读性增强。

标签： php exception business-logic control-flow

【解决方案1】：

如果您遇到一个毫无疑问是致命的错误，并且无法从中恢复，请清理并退出。如果您在当前过程的范围之外没有清理工作（关闭文件/数据库连接/无论如何，生成一些错误输出等），那么简单的exit 是最有意义的。如果错误可能是可恢复的，或者您想以一种有序的方式通过当前过程之外的某种方式清理/记录错误，那么异常是最有意义的。这是一个个案决定。

I've have heard exceptions aren't to be used for flow control - 这是真的，但并不真正适用于您所描述的情况。如果您遇到实际的错误，那么异常是完全可以接受的。你不应该做的是使用异常来确定接下来执行哪一段代码，有点像goto的重新散列。

here 很好地解释了不该做什么以及为什么不做。

【讨论】：

【解决方案2】：

通常我不会使用 Exception 进行流量控制，就好像我希望在我想退出脚本的地方经常发生某些情况一样，我会使用exit() 调用。

在我看来，只有当您在代码中遇到不应发生的事情（例如传递给对象的方法或函数的无效参数）时才会抛出异常 - 即真正异常的事情。我也只会在调用代码周围有可以适当捕获和处理异常的 try-catch 块的情况下使用它们。

因此，例如，我可能会在 try-catch 块中实例化数据库连接，然后在无法建立连接的情况下让 DB 抽象层抛出异常。然后我会捕获如果数据库连接对服务的功能绝对必要，则将其和exit() 从应用程序中适当地记录下来。

对我来说，仅仅从数据库查询中获取空的结果集（即检查用户登录）并不是我不会通过抛出异常来处理的事情，而是提供适当的最终用户消息并优雅地退出脚本如果需要的话。

【讨论】：