For the last couple of weeks, we've been working to migrate some Adobe ColdFusion 10 code over to Lucee 5 code. And, we've been debugging little discrepancies along the way. Yesterday, I ran into another small divergence in the behavior between the two platforms. It seems that calling the canonicalize() function on an empty String will return NULL in Lucee 22.214.171.124. In comparison, Adobe ColdFusion always returns a String, even when canonicalize() is called on an empty String.
To see this in action, all we have to is run canonicalize() on an empty string and then try to reference the result without any safe-guards:
- value = canonicalize( "", true, true );
- writeDump( "VALUE: [#value#]" );
Obviously, this is a trite example as there would be no need to run canonicalize() on an explicitly empty String. However, imagine that the value being passed into the canonicalize() function was a dynamic, user-provided piece of content. It might hold a lot of data; it might hold no data.
That said, if we run this code in Lucee 126.96.36.199 (via CommandBox), we get the following error:
lucee.runtime.exp.ExpressionException: variable [VALUE] doesn't exist
| || || |
| || |
| || || |
As you can see, calling canonicalize() on an empty String in Lucee returns NULL. The Null return "destroys" the "value" variable, which, in turn, raises an error when we try to reference it subsequently.
Now, if we run the same code in Adobe ColdFusion 10 or ColdFusion 2018, we get the following output:
VALUE: [ ]
As you can see, in Adobe ColdFusion, calling canonicalize() on an empty String simply returns an empty String and the code continues to function.
For the most part, Lucee CFML and Adobe CFML are compatible. In our conversation work, it's just a matter of sussing-out these tiny differences. We're like 99.99% of the way there.
I have filed this as a Documentation Bug since the Lucee documentation states that canonicalize() will return a String: https://luceeserver.atlassian.net/browse/LD-122
It's a bug rather than documentation IMHO, compatibility with ACF is the expected behavior as a rule with Lucee
Ah, that's a good point. Since I'm fairly new to Lucee, I wanted to err on the side of the lesser of the two bugs. But, I think you are right - parallel functionality is the more important issue.
I'd always recommend posting to dev.lucee.org before filing a bug
It's great to see you getting involved with Lucee :)
Ben, I've created an issue for this and closed the documentation ticket:
and submitted a pull request to fix:
Holy cow, that was fast :D You guys are amazing.
Gotcha -- I didn't know about dev.lucee.org. Good to know.