We're kind of stumped because no one can pin down when this happens.
Would you all do us a favor and modify your breeze.debug.js to capture more information about the state of affairs when it throws?
Maybe you can add this:
} else {
console.log("** Aaargh! 'curContext.prevContext': " + curContext.prevContext +
" 'context.prevContext': " + context.prevContext);
throw new Error("Illegal construction - use 'or' to combine checks");
}
Grasping at straws. All info helps.
Update 26 Feb 2014
AHA! Thank you @steve, @matthias, and others!
As I privately suspected, something, somewhere, has decide to set prevContext to undeclared instead of null. I was going to recommend that we switch to "==" anyway ... which would handle both cases. Falsiness is good enough IMO. We'll get back to you when we do it (assuming no one inside the Breeze team objects to applying a fix that we can't test).
Update 27 Feb 2014
I'm running my DocCode tests with breeze.min.js in Chrome v33 and they all pass. Frustrating. Jay will run his tests with breeze.min.js in Chrome v33 too ... and we will see if any of them fail for him. I am not hopeful.
I get the expected behavior for sensible (including illegal) variations of parm (undefined, null, true, false, a string) on the line from getEntityType that @Matthias mentioned
assertParam(parm, "okIfNotFound").isBoolean().isOptional().check(false);
My static analysis of the code (who trusts that?) tells me that the first comparison operator must remain === whereas the comparison operator in the second clause can be either == or ===. The code author worked hard to make sure that the left operand was never undefined in practice; my static analysis shows that it could become undefined ... although I am unable to arrange the world so that it happens. Maybe a failure of imagination.
My static analysis of the minified code says it is correct although my minified version is different from yours, perhaps because mine is minified against an evolving copy of breeze.debug.js (somewhere closer to what v.1.4.9 will be).
// Reformatted w/ spaces and new lines for readability.
// Observe that the minifier reversed the direction of the second null test!
// That is smart and does no harm
// I can assure you the pre-minified code is the same as what you folks are reporting.
function m(a,b) {
if(a._context){
for(var c=a._context; null!=c.prevContext;) c=c.prevContext;
if(null === c.prevContext) return c.prevContext=b, a;
if(null !== b.prevContext)
throw new Error("Illegal construction - use 'or' to combine checks");
b.prevContext=a._context
}
return n(a,b)
}
Under these trying circumstances, unless we can find a failing test, we'll make a leap of faith, slaughter a chicken, rattle some bones, and change the code to this:
if (curContext.prevContext === null) {
curContext.prevContext = context;
// just update the prevContext but don't change the curContext.
return that;
} else if (context.prevContext == null) { // CHANGED TO "if null or undefined"
context.prevContext = that._context;
} else {
throw new Error("Illegal construction - use 'or' to combine checks");
}
If you can make the time, please try this in your apps and confirm that all is well.
We're shipping v.1.4.9 tomorrow (28 Feb) so please try this pronto!
