Happy to continue the conversation in the thread where I first brought this up . I am intrigued by this information as it probably will change how I use cfparam in the future. Perhaps it’s worth adding some notes to the docs on the performance implications of using cfparam’s type attribute.

I think regardless of all that, the issue still stands that the exception thrown from cfparams is not clearly identified and in my opinion it’s something that can be improved.

Your first line of defence should be validating the user input where it enters the system. The closer you are to the surface, the easier you can provide meaningful feedback to the user. If you rely on type validation right before processing data, you are usually too deep already and now need a trace of what has happened and why it happened. Hence you are asking here for more detail and an easier way to programmatically detect the exception reason. Treat an exception as what it is: an exceptional bad state, and the exception handling is your last line of defence to prevent processing bad data and potentially corrupt the system. Bad user input certainly isn't an exceptional case, it's common and should be treated like that. There's a lot of documentation around exception handling and pitfalls in Java's checked exceptions and there are popular languages around, where exceptions are even discouraged in favor of proper error handling (Go, Swift). Note: I'm not saying that exceptions are not needed, just that they are not needed for user input validation.

Adobe recommends using <cferror> when using <cfparam> for validation. This allows proper context (catching expression exception). But I guess this is even more inconvenient to you.

(As this is off-topic, this will be my last comment here.)

Validate user input with more appropriate checks beforehand, e.g. using isValid.

I can only use isValid() if I set my cfparam to any. It will thrown an error before I get the chance. It is not my do-it-all solution. Using cfparams to validate the type of a url variable is the first line of defense.

What you are suggesting is to do the following:

That’s a lot of extra unnecessary code compared to

Use Application.cfc’s onError handler for this.

Yes, of course. That is how I handle cfparam errors. Unfortunately there is no way to detect that the error is in fact from a cfparam in the onError and handle it appropriately.. hence this ticket The messages should make it clearer where the error came from so we can in fact handle it better without relying on hacky workarounds.

Just to be clear. CFPARAM is not a catch all solution for me. It is the first line of defence. There are further validations in cfqueryparam, cfarguments etc.. Especially because it is the first line of defence, it is important to be able to handle these errors clearly.

Use Application.cfc’s onError handler for this. The onError event acts as a middleware for all unhandled exceptions. You can inspect the exception struct, check for cast issues, and do your actions accordingly.

Independently, you should probably not use the type attribute validation as protection to begin with. Validate user input with more appropriate checks beforehand, e.g. using isValid. It’s less expensive compared to creating an exception and filling the stacktrace. Treat type validation as last resort consequential error prevention, not as your “do-it-all” solution.