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