Error "Type" Isn't Always A String In Adobe ColdFusion
Yesterday, while working on Dig Deep Fitness, my ColdFusion fitness tracker, I accidentally consumed an ordered struct as if it were an array. As expected, ColdFusion threw an error; however, my centralized error handling logic broke because the type property of the thrown error was not a string, it was a complex Java object. I don't think I'd ever run into this issue before - I've always believed that the type, message, detail, and extendedInfo properties were guaranteed to be a string. I guess not.
This outcome is easy to reproduce:
<cfscript>
try {
// Create an ORDERED STRUCT.
data = [:];
// Accidentally use it like an ARRAY in CFLOOP.
cfloop( item = "item", array = data ) {
// ....
}
} catch ( any error ) {
writeDump( error );
}
</cfscript>
As you can see, I'm accidentally looping over data as if it were an array. And, when I try to do this in Adobe ColdFusion, we get the following output:
As you can see, the Type property on the caught error is not a string but a complex Java object. Unfortunately, I have logic in my error handling that assumes that this value will always be a string; and, that I can call string member methods on it. It turns out that I cannot assume this to be true.
ASIDE: In Lucee CFML, this doesn't throw an error because Lucee will happily treat "array like" structs as arrays.
Probably, what I need to do is a pass the error object through a "normalization" routine within my centralized error handling. This way, I can create an object that has a guaranteed structure (which guaranteed data-types). Kind of a bummer; but, we live and we learn.
Want to use code from this post? Check out the license.
Reader Comments
Ha ha, I just ran into this again, but for basically the same reason. I accidentally used an integer at the
array=""portion ofcfloop.Great timing. I'm just poking into why some errors getting logged in a legacy application. It does assume that type will always exist and be a string. That may be part of the problem. Cheers.
@Allen,
Please report back when you've figured it out :D
This is a bug. Log it.
Type should be a string. And CF should never be bubbling a Java type back to CFML.
Also if you check what the type actually is (
writeDump(error.type.getClass().getName())), it's justjava.lang.Classwhich will not be intentional.It's just sloppy dev from the CF Team.
You just re-subscribed me to this article because reasons.
So... did you raise the ticket with Adobe?
@Adam, "well actually" (adjusts glasses) you were never subscribed in the first place due to a bug in my code (apparently the unit tests that I don't have never caught the logic problem in my update).
I don't think I did file a bug - I got distracted. Will do so now and post ticket.
I can't believe your non-existent tests didn't catch this! Weird
It's probably what Einstein was talking about when he referred to "spooky action at a distance." 😉
Anyway, bug filed: CF-4221198.
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →