tracker issue : CF-4021994

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.

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.

+1..........................................................

Vote by External U.

This seems like a bad idea. Changing existing code from a loop to using Each could break error handling.

Vote by External U.

this bug impacts productivity and that's why I am adding a vote

Vote by External U.

+1 .............................................

Vote by External U.

...........................zzzzzz

Vote by External U.

Which version is this fixed in, pls?

Comment by External U.

+1 ......................

Vote by External U.

Hello???

Comment by External U.

Says fixed, ok which version?

Comment by External U.

Jesus, Adobe, how hard is it to answer this question?

Comment by External U.

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.

Yes, where is this promised "fix"?

Comment by External U.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Unfixed. The fix doesn't cover the scope of the bug.

Comment by Aaron N.

We are working on a complete fix for this issue, and will make it available in due time.

Comment by Immanuel N.

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

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.

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.

For anyone looking for the open bug on this issue, it's CF-4198734.

Comment by Samuel K.

oh nvmd, I see Immanuel already pointed it out, my bad. Missed that one.

Comment by Samuel K.

Hi Adobe, I've verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513). Well, excluding the portion covered by CF-4198734, that is. Thanks!, -Aaron

Comment by Aaron N.