我正在阅读cfthrow 的文档并遇到了这个
何时使用 cfthrow 标签
当您的应用程序可以识别和处理特定于应用程序的错误时，请使用 cfthrow 标记。cfthrow 标记的一种典型用途是实现自定义数据验证。cfthrow 标记对于将错误从自定义标记页面抛出到调用页面也很有用。
例如，在用于设置密码的表单操作页面或自定义标签上，应用程序可以确定输入的密码是最小长度，还是包含字母和数字，并抛出错误消息，指示密码规则坏了。cfcatch 块处理错误并告诉用户如何更正问题。
我一直都做错了吗，或者这只是一个可怕的用例？
我被告知不应使用异常来处理常规的应用程序流程，而应使用某些超出您控制的东西。例如，一个文件在您写入时被锁定。
违反密码规则的用户听起来不像是您无法控制的事情。
That is a poor example not a poor use case. I personally would pass in the parameters to a validation function and return a result that contained a pass or fail and a collection of failure messages to display to the user.
How I use exceptions is as follows.
Within functions. Let's say that you have a function that you are getting some data from the database and you are then constructing a structure from it. If the query returned has no values you have several options:-
You could return an empty structure and let the calling code deduce the problem from the fact the structure is empty. This is not ideal because then the application has to have complicated logic to address the missing data.
You could return a more complex datatype where one property is whether the process went ok and the actual data. Again this is not optimal as you have to then make this access the property on every call when the majority of the time you have data and again your application is dealing with this issue.
Or you could raise a custom exception with cfthrow indicating that there is no record that matches. This then means that you can choose to ignore the prospect of this error happening and let it bubble up to the onError handler or you could surround it in a try catch statement and deal with it there and then. This keeps your API clean and sensible.
Wrapping external errors let's say that you connect to an external API using cfhttp over https. Now this requires installing the certificate in your keystore otherwise it throws an error. If this certificate gets updated then it will start erroring again. In this instance I would wrap the call in a try catch and should this be the error I would wrap that in my own custom exception with a message detailing that we need to update the cert in the keystore so that any developer debugging it knows what to do to fix it without having to work it out. If it is not that particular error then I would cfrethrow it so that it bubbles up and is dealt with by whatever exception handling logic is above the call.
These are just a few examples, but there are more. To summarise I would say that throwing exceptions is a way of communicating up through the tiers of an application when something has occurred that is not the hoped for behaviour while keeping your API/Application logic clean and understandable.
这真的取决于你的判断力。在许多语言中，对所有内容都使用异常是非常常见的，包括输入验证。
重要的是，异常与您是否可以控制某些事情无关。例如，假设您有一个相当长且复杂的模块来上传文件。类似的事情有很多失败点：文件可能太大，文件可能是错误的格式等。无一例外，你唯一的选择是大量的 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">）。
此外，从技术上讲，破解密码的用户超出了您的控制范围，因为用户已经确定了密码的值。也就是说，我讨厌密码规则，因为它们总是使维护安全变得更难，而不是更容易。