I'm having trouble setting up a cbValidation custom validation udf. In the documentation example (https://coldbox-validation.ortusbooks.com/advanced/advanced-custom-validators#closure-lambda-validator) a lambda is used to define the udf. As far as I know, that syntax is only available in CF2021 and Lucee 5. I'm using CF2018 and am struggling with how to write that udf without using a lambda (

=>

) expression. Here's my cbValidation code:

cbValidation.validateOrFail(
    target = rc,
    constraints = {
        facilityid : {
            required : true,
            requiredMessage : "A {field} (FID) must be provided."
            type : "integer",
            typeMessage : "The {field} must be a whole number greater than 1.",
            min : "1",
            minMessage : "The {field} must be a whole number greater than 1.",
            udf : function ( value, target ) {
                if( isNull( arguments.value ) ) return false;
                return ecFacilityService.getByFacilityID( facilityid = arguments.value, lazyload = true ).len() > 0;
            },
            udfMessage : "There are no facilities with a {field} value of {rejectedValue}."
        }
    }
);

This throws a ColdFusion "Invalid Construct: Either argument or name is missing". Not sure what I'm doing wrong.

There's a comma missing after the

requiredMessage

text.

Doh. 🤦

@cfvonner a hint for next time... always pay attn to the error. If it's a compile error (like this clearly is), then "I'm having trouble setting up a cbValidation..." is irrelevant. If the code dun't compile, it doesn't matter whose lib yer trying to use. Anything about "syntax" or "constructs" is just the compiler going "get tae fuck"

Fair cop. Unfortunately, closure functions have a tendency to swallow error details (the best I got was it was somewhere in the code starting at the line with

cbValidation.validateOrFail

). The problem was I forgot that I had added that requiredMessage line before I added the udf line, and I assumed the error was coming from the way the udf part was written.

This is interesting, and I don't doubt you, and I know that there's an issue with closures swallowing errors. But... "a closure function" is something that only exists at runtime... it's just a bunch of characters at compile time; the CFML engine ain't even able to work out if it's a closure function, let alone whether there's an error to swallow when it's called. Unless - of course - CF does something really weird when it parses CFML that has functions in it, and pulls them out as separate compilable entities (like how they do with functions in a CFC, for example...)

I'll readily admit I made an assumption: that the only thing that had changed in my code was the addition of the

udf

key to the constraints and it's associated closure, and therefore that the error was coming from a compile error on that closure. Oddly, in testing something similar on TryCF to try to narrow down where the problem was coming from (I created a function assigned to a variable), it threw errors on CF2018 but not on any other version (I tried 11, 2016 & 2021 to be sure). I wonder if there was a closure/function expression error on CF2018 that was later fixed by a hotfix that hasn't been installed on TryCF yet. When I tried the same code on my local CommandBox-driven CF2018 server running the latest hotfixes it ran fine. Which left me very perplexed. Here's the Gist that failed on TryCF: https://gist.github.com/cfvonner/363ba307b239fbb66b615569f2c9b0aa / https://trycf.com/gist/363ba307b239fbb66b615569f2c9b0aa?engine=acf2018

I love @abram. I love trycf.com. But I can't fucking stand the way it doesn't just emit the original error.