Skip to main content
Ben Nadel at CFCamp 2023 (Freising, Germany) with: Luis Majano and Jürg Anderegg
Ben Nadel at CFCamp 2023 (Freising, Germany) with: Luis Majano ( @lmajano ) Jürg Anderegg

Error "Type" Isn't Always A String In Adobe ColdFusion

By
Published in Comments (8)

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:

ColdFusion error data structure that has a Java object as the Type property.

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

15,781 Comments

Ha ha, I just ran into this again, but for basically the same reason. I accidentally used an integer at the array="" portion of cfloop.

1 Comments

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.

20 Comments

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 just java.lang.Class which will not be intentional.

It's just sloppy dev from the CF Team.

15,781 Comments

@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.

Post A Comment — I'd Love To Hear From You!

Post a Comment

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel