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