tracker issue : CF-4021994

select a category, or use search below
(searches all categories and all time range)
Title:

ColdFusion masks correct exception when exception is thrown from within an iteration method using a function expression

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 07/16/2015

Components: Language, Exception Handling

Versions: 11.0

Failure Type: Data Loss

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Normal / Some users will encounter

Locale/System: ALL / Platforms All

Vote Count: 12

Listed in the version 2016.0.0.297996 Issues Fixed doc
See: http://blog.adamcameron.me/2015/07/cfml-coldfusion-does-some-dodgy.html

Basically if an exception is raised within the method version of an iteration function (eg: Array.each()), and the callback is a function expression, then CF replaces the original exception with a vanilla Application exception.

Please stop doing that.

Can you also please explain why you are doing this in the first place? It seems a bit odd.

Cheers

-- 
Adam

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4021994

External Customer Info:
External Company:  
External Customer Name: Adam
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

FWIW, Clojure attempted to do this sort of exception wrapping a while back and it caused havoc with real world code so they backed off and left exceptions unwrapped. I cannot imagine _why_ the CF team think exceptions need to be wrapped in this case? It's a really bad idea in my opinion.
Vote by External U.
6621 | July 16, 2015 02:04:24 PM GMT
This makes no sense as it produces the wrong expectation for inline exceptions that should bubble up. Please do not wrap it.
Vote by External U.
6622 | July 16, 2015 02:17:05 PM GMT
+1..........................................................
Vote by External U.
6623 | July 16, 2015 02:24:49 PM GMT
This seems like a bad idea. Changing existing code from a loop to using Each could break error handling.
Vote by External U.
6624 | July 16, 2015 03:20:24 PM GMT
this bug impacts productivity and that's why I am adding a vote
Vote by External U.
6625 | July 16, 2015 04:05:57 PM GMT
+1 .............................................
Vote by External U.
6626 | July 16, 2015 04:30:02 PM GMT
...........................zzzzzz
Vote by External U.
6627 | July 16, 2015 04:54:25 PM GMT
Which version is this fixed in, pls?
Comment by External U.
6600 | September 24, 2015 01:40:09 AM GMT
+1 ......................
Vote by External U.
6628 | September 26, 2015 09:01:32 PM GMT
Hello???
Comment by External U.
6601 | February 10, 2016 08:16:39 AM GMT
Says fixed, ok which version?
Comment by External U.
6602 | February 27, 2016 12:23:55 AM GMT
Jesus, Adobe, how hard is it to answer this question?
Comment by External U.
6603 | May 20, 2016 08:55:08 AM GMT
Just realized this bug was why I couldn't see where my actual errors were coming from. This "fix" needs to be actually made available to us poor end users.
Vote by External U.
6629 | May 20, 2016 08:57:08 AM GMT
Yes, where is this promised "fix"?
Comment by External U.
6604 | May 20, 2016 08:57:29 AM GMT
Any chance we could find out which update had the fix for this in it? We've been waiting since at least 9/24/15 for an answer on this!
Comment by Carl V.
6605 | May 05, 2017 09:37:00 PM GMT
I am now the 7th person, asking the same simple question: What version is this fixed in!? :) Of course, if Adobe would always populate the FIXED IN BUILD field - then we'd not have to keep pestering ;) That additional few seconds, to fill in that field, when closing tickets - that'd be mutually-beneficial to both Adobe and us. Thanks!, -Aaron
Comment by Aaron N.
6606 | May 05, 2017 09:46:22 PM GMT
This bug was fixed with released build of CF2016. This was also fixed in CF 11 update 11 (11,0,11,301867). Sorry for the delayed response ! Thanks, Suchika
Comment by Suchika S.
6607 | May 08, 2017 08:05:17 AM GMT
This is not fixed. #1) The exception is still listed as "An exception occurred while calling the function each." This is not the exception; this is part of the stack trace. The exception should indicate WHAT went wrong; the line number & stack trace tell us where. #2) If you nest two or more member functions, you can break it, due to the manner in which it appears somebody tried to dodge actually fixing this, e.g. thingArray = [[1,2,3],[4,5,6],[7,8,9]]; thingArray.each(function(item){ item.each(function(subItem) { writedump(f); }); Result: An exception occurred while calling the function each. An exception occurred while calling the function each. Could you fix this such that member function errors are thrown and reported in exactly the same manner that other errors are thrown and reported?
Comment by Samuel K.
6608 | May 09, 2017 02:04:58 PM GMT
Additionally, even when the error is reported (by appending the detail to the error string), the line number given is the line number of each(), not the line number of the actual error.
Comment by Samuel K.
6609 | May 12, 2017 07:53:08 PM GMT
To clarify, the issue we fixed here was to do with custom exceptions being nested within a generic exception. We now return only the custom exception, along with the stacktrace which has a reference to the line number where error generated. Here's a sample code to test the fix, try { a = [1,2,3]; a.each(function(){ throw(type="InsideEachException", message="Blam", detail="An exception raised inside a closure function"); }); } catch(any e){ writeDump(e); } Samuel Knowlton, the issue you raise is beyond the scope of the fix for this bug. Could you please raise a seperate bug?
Comment by Immanuel N.
6610 | May 16, 2017 07:03:46 AM GMT
That's nonsense, Immanuel. Samuel's example very much *is* another symptom of the same issue (once one fixes the synatx errors, anyhow ;-). Don't just cherry-pick a known-good test case that proves your point: that's tantamount to saying "it works OK on my machine". Samuel has given you another case which *isn't* fixed by whatever bandaid you slapped on this to make it go away. Here is a syntax-error-free version of Samuel's code: <cfscript> thingArray = [[1,2,3],[4,5,6],[7,8,9]]; thingArray.each(function(item){ item.each(function(subItem) { writedump(f); }); }); </cfscript> And here's the error: An exception occurred while calling the function each. An exception occurred while calling the function each. The error occurred in C:/src/test.cfm: line 3 Called from C:/src/test.cfm: line 4 Called from C:/src/test.cfm: line 3 Called from C:/src/test.cfm: line 4 Called from C:/src/test.cfm: line 3 Called from C:/src/test.cfm: line 5 Called from C:/src/test.cfm: line 4 Called from C:/src/test.cfm: line 3 Called from C:/src/test.cfm: line 5 Called from C:/src/test.cfm: line 4 Called from C:/src/test.cfm: line 3 1 : <cfscript> 2 : thingArray = [[1,2,3],[4,5,6],[7,8,9]]; 3 : thingArray.each(function(item){ 4 : item.each(function(subItem) { 5 : writedump(f); now... here is a version of the code using arrayeach instead of of Array.each: <cfscript> thingArray = [[1,2,3],[4,5,6],[7,8,9]]; arrayeach(thingArray,function(item){ arrayeach(item,function(subItem) { writedump(f); }); }); </cfscript> And the error: Variable F is undefined. The error occurred in C:/src/test2.cfm: line 5 Called from C:/src/test2.cfm: line 4 Called from C:/src/test2.cfm: line 3 3 : arrayeach(thingArray,function(item){ 4 : arrayeach(item,function(subItem) { 5 : writedump(f); 6 : }); 7 : }); So what you see on the first example is CLEARLY still a case of "ColdFusion masks correct exception when exception is thrown from within an iteration method using a function expression". What you SHOULD be saying here is "thanks for providing another case of this issue... it clearly shows our fix was incomplete: we'll crack on with getting that sorted out. Thanks for taking the time to help improve ColdFusion".
Comment by Adam C.
6611 | May 16, 2017 07:32:51 AM GMT
Don't think I have anything to add to Adam's reply, except to second: >> To clarify, the issue we fixed here was to do with custom exceptions The ticket isn't about custom exceptions. It's about exactly what the description and my comment say that it's about. It is obvious upon a cursory inspection that the "solution" you've implemented here is a workaround (trying to grab the relevant exception text and just append it to the member function error and hope that will be fine). A proper solution means that a developer should not be able to distinguish between an exception and a stack trace in a member function and an exception/stack trace outside a member function, because the same information is presented in the same format. The extent to which the scope of your fix is different than the scope required does not appear to be a problem with the ticket's scope, but the existing "solution's" scope.
Comment by Samuel K.
6612 | May 16, 2017 12:39:51 PM GMT
OMFG, I just twigged what Immanuel has done. He's just fixed - specifically - my original repro case. He's not actually attempted to fix the underlying issue, just taken that one situation and popped a bandaid over it. And whats worse, having been *called on that*, he's pretended that that is what the task at hand was in the first place. Bloody hell that's disingenuous. Immanuel mate: you've been rumbled. Just fix the issue properly.
Comment by Adam C.
6613 | May 16, 2017 12:48:17 PM GMT
Unfixed. The fix doesn't cover the scope of the bug.
Comment by Aaron N.
6614 | May 19, 2017 05:20:12 AM GMT
We are working on a complete fix for this issue, and will make it available in due time.
Comment by Immanuel N.
6615 | May 26, 2017 09:18:08 AM GMT
*bump* Sigh. It's apparent that this ticket isn't being revisited. Does someone want to re-file this ticket to get it fixed properly? Why this was fixed only for custom exceptions, and not all exceptions, is beyond me. Thanks!, -Aaron
Comment by Aaron N.
6616 | September 13, 2017 07:12:16 AM GMT
Apologies for the delayed reply. We acknowledge the fix made here is incomplete, and have raised a separate bug, CF-4198734, to ensure this is fixed appropriately. This bug is not being re-opened since the fix made has gone out with a previous release, and that information needs to be maintained.
Comment by Immanuel N.
6617 | September 14, 2017 04:01:41 AM GMT
Hi Immanuel, Thanks very much! I see you already took care of that a few months ago (as per your May 26th comment that is now visible). Very good work. And sorry I didn't notice you'd already logged another ticket. Thanks again!, -Aaron
Comment by Aaron N.
6618 | September 14, 2017 05:52:27 AM GMT
For anyone looking for the open bug on this issue, it's CF-4198734.
Comment by Samuel K.
6619 | September 14, 2017 04:49:26 PM GMT
oh nvmd, I see Immanuel already pointed it out, my bad. Missed that one.
Comment by Samuel K.
6620 | September 14, 2017 04:52:42 PM GMT