我正在阅读cfthrow的文档并遇到了这个
何时使用 cfthrow 标签
当应用程序可以识别和处理时，请使用 cfthrow 标记 特定于应用程序的错误。cfthrow 标签的一个典型用途是 实现自定义数据验证。cfthrow 标签也很有用 用于将错误从自定义标记页面抛出到调用页面。
例如，在表单操作页面或用于设置 密码，应用程序可以判断是否输入了密码 是最小长度，或同时包含字母和数字，并抛出 错误，并显示指示已破坏的密码规则的消息。 cfcatch 块处理错误并告诉用户如何更正 问题。
我一直做错了还是这只是一个糟糕的用例？
我被告知，异常不应该用于处理常规的应用程序流，而应该用于您无法控制的事情。 例如，当您去写入文件时，该文件被锁定。
用户违反密码规则听起来不太像是您无法控制的事情。
这是一个糟糕的例子，而不是一个糟糕的用例。我个人会将参数传递给验证函数，并返回一个包含通过或失败的结果以及要向用户显示的失败消息集合。
我如何使用异常如下。
在函数内。假设您有一个函数，即您从数据库中获取一些数据，然后从中构造一个结构。如果返回的查询没有值，您有以下几种选择：-
-
您可以返回一个空结构，并让调用代码从结构为空的事实中推断出问题。这并不理想，因为应用程序必须具有复杂的逻辑来解决丢失的数据。
-
您可以返回更复杂的数据类型，其中一个属性是流程是否正常以及实际数据。同样，这不是最佳选择，因为当大多数时候您有数据并且您的应用程序再次处理此问题时，您必须在每次调用时对此访问属性。
-
或者，您可以使用 cfthrow 引发自定义异常，指示没有匹配的记录。这意味着您可以选择忽略此错误发生的前景，并让它冒泡到 onError 处理程序，或者您可以在 try catch 语句中将其包围并在那里处理它。这样可以保持 API 干净和合理。
包装外部错误 假设您使用 cfhttp over https 连接到外部 API。现在，这需要在密钥库中安装证书，否则会引发错误。如果此证书得到更新，那么它将再次开始出错。在这种情况下，我会将调用包装在 try catch 中，如果这是错误，我会将其包装在我自己的自定义异常中，并附上一条消息，详细说明我们需要更新密钥库中的证书，以便任何调试它的开发人员都知道该怎么做来修复它而无需解决它。如果不是那个特定的错误，那么我会 cfrethrow 它，以便它冒泡并由调用上方的任何异常处理逻辑处理。
这些只是几个例子，但还有更多。总而言之，我想说的是，抛出异常是一种在发生非预期行为时通过应用程序层进行通信的方式，同时保持 API/应用程序逻辑干净且易于理解。
这真的取决于你的判断。在许多语言中，对所有内容（包括输入验证）使用异常是极其常见的。
重要的是，例外与某些事情是否在您的控制范围内无关。例如，假设您有一个相当长且复杂的模块来上传文件。这样的事情有很多失败点：文件可能太大，文件格式可能错误，等等。无一例外，您唯一的选择是大量的if/then检查和最后的某种状态返回。除了例外，您所要做的就是使用一组 cfthrows：
<cfthrow type="FileUpload.TooBig" message="The file size was #FileSize#, but the maximum size allowed is #MaxFileSize#">
<cfthrow type="FileUpload.WrongType" message="The file type was #FilType#, but the accepted types are #AcceptedTypeList#">
然后，任何调用文件上传函数的东西都可以捕获<cfcatch type="FileUpload">或捕获特定的（例如 <cfcatch type="FileUpload.WrongType"> ）。
此外，从技术上讲，用户破解密码是您无法控制的，因为用户已经确定了密码的值。也就是说，我讨厌密码规则，因为它们总是使维护安全性变得更加困难，而不是更容易。