How to handle cfparam errors neatly?

dev support
#1

I’m a little baffled. There doesn’t seem to be an easy way to detect cfparam type casting errors.

Before switching to Lucee I would do a check on the error message thrown for the string “Invalid parameter type” in my general error handler and then handle those errors differently to other ones. I’ve found almost all these errors are bot generated.

In Lucee the error message look like this: “Can’t cast String [sd] to a value of type [numeric]” which does not indicate that the casting was attempted in a parameter. It seems it could be triggered by any number of things.

The best I can do is inspect the Tagcontext to try and deduce what the error is about. But that just feels so clunky for something that in my view should not be so difficult.

What would be ideal is for there to be a specific Error Code provided for cfparam validation failures.

If I’m missing something here, let me know.

Lucee Version: 5.3.6.61

#2

this was proposed a while ago [LDEV-221] allow to set a handler for cfparam type invalid values - Lucee

#3

That would also be a good solution and certainly give a nice level of control.

At a minimum though, it would be great if the error message was identifiable as coming from a cfparam tag. For example instead of

"Can’t cast String [sd] to a value of type [numeric]”

it could be

"Can’t cast String [sd] to a value of type [numeric] as required by cfparam”

or something similar.

As it is, you have to dip into tagcontext (possibly not available) to work out if this came from a cfparam, cfargument or cfqueryparam or maybe some other place where casting failed.

#4

can you file a bug?

I’d make the change but it’s a little more complex cfparam is now handled inline by a Translation Time Transformer

the syntax for exceptions is to wrap tag names etc with brackets, ie Tag [param]

#5

Sure. I’ve filed an issue here [LDEV-3295] An easier way of identifying CFPARAM validation errors - Lucee

#6

Of course, you could just create your own cfml version

It’s just basically, var exists? no? use default, otherwise check if it can be cast to the type specified

#7

I’ve got 1500+ uses of cfparam in my code base. Not really keen to be messing with that by rolling my own. But you’re right - it is an option and might make sense for smaller projects.

#8

Since I’ve been heads-down in ColdFusion custom tags for the last few weeks, I saw this thread and was inspired to try and create a custom tag, cf_specify that would wrap the cfparam tag and expose more detailed information about the error:

1 Like
#9

Nice work. I did end up creating a wrapper actually, not too dissimilar to what you did there. I think it probably is the best way to handle cfparam errors neatly at the moment.