我只是在寻找一些最佳实践建议。
我有一个服务，“价格表服务”，用户可以在其中保存某种价格表。
有一些实例或配置可能会留下不一致的数据，在那些事件中我想结束函数执行。
例如，如果未在对象上设置customerId，或者在数据库中找不到销售人员的userId。
<小时/> 我的问题是，当遇到业务逻辑错误时，保留函数的最佳方法是什么？
我喜欢Exceptions在那里停止执行的方式，并允许你重新抛出异常。问题是，我听说过异常不能用于流量控制。
目前我只有一堆嵌套的if / elses，除非$service_error_message的局部变量尚未设置，否则我不提交我的交易。
如果$service_error_message为空，那么我知道我的验证器都没有失败，可以保存。
有没有人建议如何更好地处理这些情况？
答案 0 :(得分：2)
如果您遇到无可置疑的致命错误，无法从中恢复，请清理并退出。如果你没有在当前程序范围之外做任何清理（关闭文件/数据库连接/无论如何，产生一些错误输出等），那么简单地exit就是最有意义的。如果错误可能是可恢复的，或者您希望通过当前过程外部的某种方式以有序的方式清除/记录错误，则异常最有意义。这是个案决定。
I've have heard exceptions aren't to be used for flow control - 这是真的，但并不适用于您所描述的情况。如果您遇到实际的错误，那么异常是完全可以接受的。您不应做的是使用异常来确定接下来执行哪一段代码，重新排列goto。
可以找到关于不该做什么以及为什么不做的一个很好的解释here。
答案 1 :(得分：1)
通常情况下，我不会将Exception用于流量控制，就好像我期望一些条件经常发生在我想要摆脱脚本的地方我会使用exit()调用。
在我看来，只有在代码中遇到不应该发生的事情时（例如传递给对象方法或函数的无效参数），才会抛出异常 - 即真正例外的事情。我也只会在调用代码周围有try-catch块的情况下使用它们，这些块可以适当地捕获和处理异常。
因此，例如，我可能有一种情况，我在try-catch块中实例化数据库连接，然后让DB抽象层在无法建立连接的情况下抛出异常。然后我会抓住它例外，如果数据库连接对服务功能绝对必要，则将其和exit()适当地从应用程序中记录下来。
对我来说，只是从数据库查询中获取空结果集（即检查用户登录）不是我不会通过抛出异常来处理的，而是提供适当的最终用户消息并优雅地退出脚本如果需要的话。