Just a note: using <cfloop> works fine.  It's just <cfoutput> that's
bung.  That might narrow-down the search for the bungness..?

--
Adam

On Jul 22, 7:53 pm, Adam Cameron <[email protected]> wrote:
> G'day:
> Just before I start, I would like to vent some frustration.
>
> I am working on a side project after-hours, only getting a chance to
> work on it for a few hours on the weekend, and the odd evening after
> work such as now.  One of the original requirements of this project is
> that it must work in CF8 & OBD.  In the last three sittings that I
> have had - about six hours all up, I guess - I have only managed to
> move forward with my own work by about 15 lines of code.  All the rest
> of the time has been taken up puzzling over bugs in OBD, replicating
> them, and logging them (well: blathering on about them on this forum,
> anyhow ;-).  I am now very very hesitant about whether I think OBD is
> production-ready, to be frank.  It's not like I'm going out of my way
> to find these things, and it's also not like they're particularly
> esoteric edge cases either.  All I'm currently doing in this project
> is writing unit tests, after all: not complicated stuff.
>
> I have now recommended to my client that we shelve the idea of OBD,
> and I'll perhaps be looking @ Railo instead.  Or for heaven's sake
> can't they just stick with CF! [grumble].
>
> I'm not cross or anything, and I don't at all mean to take away from
> your hard work on this project, because it's certainly very impressive
> what you have achieved, and on the whole I've found my time on this
> forum an OK experience, and you've helped me a lot.  And for that I am
> very grateful.  I just think it might be useful for me to share my
> experience and... um... "standpoint", I guess, as well as bringing the
> bugs to your attention.
>
> And now for the bugs.
>
> Today I found one bug, and then whilst contriving the test case for
> it, found another one.
>
> First.  The bug in <cfreturn> / <cfoutput>
>
> Consider this code:
>
> <!--- ReturnInQueryLoop.cfc --->
> <cfcomponent>
>
>         <cffunction name="f">
>                 <cfargument name="id">
>                 <cfscript>
>                         var aDebug = arrayNew(1);
>                         var q = queryNew("");
>                         var b = false;
>                         arrayAppend(aDebug, "Initalised");
>                         queryAddColumn(q, "id", listToArray("1,2,3"));
>                         queryAddColumn(q, "data", 
> listToArray("one,two,three"));
>                         arrayAppend(aDebug, q);
>                 </cfscript>
>                 <cfoutput query="q">
>                         <cfset b = q.id eq arguments.id>
>                         <cfset arrayAppend(aDebug, "currentRow: #currentRow#. 
> #q.id# eq
> #arguments.id# = #b#")>
>                         <cfset arrayAppend(aDebug, "THIS SHOULD WORK TOO (but 
> doesn't))!
> currentRow: #currentRow#. #q.id# eq #arguments.id# = #q.id eq
> arguments.id#")>
>                         <cfif q.id eq arguments.id>
>                                 <cfset arrayAppend(aDebug, "I am about to 
> return out of this
> method")>
>                                 <cfreturn currentRow>
>                                 <cfset arrayAppend(aDebug, "This is after the 
> CFRETURN, but I
> never get hit")>
>                         </cfif>
>                 </cfoutput>
>                 <cfset arrayAppend(aDebug, "Oops... I am still IN this 
> method?!?!")>
>                 <cfdump var="#aDebug#">
>                 <cfabort>
>         </cffunction>
>
> </cfcomponent>
>
> <!--- returnInQueryLoop.cfm --->
> <cfset o = createObject("component", "ReturnInQueryLoop")>
> <cfoutput>#o.f(id=2)#</cfoutput>
>
> If you look at this, you will see that there's no real way one should
> end up outside the bottom of the <cfoutput> block.  The return
> statement should trigger on the second row of the query, because 2
> does indeed equal 2.  Indeed the <cfreturn> statement *does* trigger,
> but all it does is the equivalent of a <cfcontinue>: skipping to the
> next iteration of the loop.  It doesn't actually return!!
>
> CF8 performs exactly as one would expect here (ie: 2 gets output on
> the screen, and that's it).
>
> So that's not a great one.
>
> And the second bug is with this line:
> <cfset arrayAppend(aDebug, "THIS SHOULD WORK TOO (but doesn't))!
> currentRow: #currentRow#. #q.id# eq #arguments.id# = #q.id eq
> arguments.id#")>
>
> What that appends to the array is the word "no".  This has something
> to do with this expression:
> #q.id eq arguments.id#
>
> Because if I remove it, I then get the string appended to the array as
> one might expect.
>
> Again, no such issue on CF8.
>
> Please note: this is not some weirdo contrived case I have
> concocted... the original code was within MXUnit... I've just
> refactored it into a simple repro case as part of working out WTF was
> going on (needless to say, it took a bit of guessing, because I really
> really didn't expect <cfreturn> to not work properly!!
>
> Fortunately this is only biting me on the bum in a unit test I had
> written to test a bug in MXUnit itself (you guys are not the only ones
> I harangue with bugs, trust me... MXUnit, MockBox and Adobe all get it
> too.  Oh boy do Adobe get it ;-).  I've finished testing MXUnit, so I
> can remove the test now and crack on with my other tests.  However at
> least the first one is not an insignifcant bug, so it'd be really good
> if you could look at it.  The second one is a curio more than anything
> else.  And it was funny (to me... my sense of "humour" is weird) that
> I found a bug whilst trying to troubleshoot another bug...
>
> Right.
>
> I'm off to install Railo and rerun my unit tests and see what grief I
> get with that.
>
> Cheers.
>
> --
> Adam

-- 
Open BlueDragon Public Mailing List
 http://www.openbluedragon.org/   http://twitter.com/OpenBlueDragon
 online manual: http://www.openbluedragon.org/manual/

 mailing list - http://groups.google.com/group/openbd?hl=en

Reply via email to