This blog post is in response to this blog post "Regular expressions – practical examples to get you started". (My comment wasn't accepted after submitting twice and I'd rather post it somewhere that I have a little control as Adobe's community content tends to get deleted over time.)
We've encountered some unpreventable ColdFusion hard errors (that can't be prevented using try/catch) when using ReReplaceNoCase() in our application framework. Here are some reported bugs that are similar:
- https://tracker.adobe.com/#/view/CF-3928688
- https://tracker.adobe.com/#/view/CF-4165797 (Note: I'm "External U" and I never withdrew this bug.)
To work around this intermittently occuring bug (which Adobe classifies as "UserError" or "AsDesigned"), we started casting the initial value as a string (required for Java; not all CF-typeless variables contain pure "string" values) and using Java's replaceAll(). Our functions now seem faster, but more importantly there's no occasional CFError occurring in any of our apps.
When using regular expressions with ColdFusion, the ReEscape() function (available since CF10, but not available in Lucee at the time of this article) simplifies escaping characters that match regular expression control characters.
If interested in using more regex matching functions in ColdFusion, check out Ben Nadel's JRegEx:
https://www.bennadel.com/blog/3322-jregex—a-coldfusion-wrapper-around-java-s-regular-expression-patterns.htm
UPDATE 2/4/20201
Apparently using replace() with high ASCII characters (ie emojis) can be problematic too. (Reported in CF2018; Fixed in CF2021)
https://tracker.adobe.com/#/view/CF-4206938
Top comments (1)
That's really funky! I am only guessing here, but I imagine this has something to do with a "catastrophic backtracking" issue? I honestly don't know what that is, but it always shows up in SEC scans in dependabot (and other security scanning tools). I'm not sure I've run into this issue before -- or rather, I hope it at least gets logged properly (as StackOverflow) and doesn't just get lost in the ether. Very strange!
But yeah, the Java-layer RegEx is always faster (in my experience) and is much more robust in functionality.