#162 new
nickg

ANT keeps on truckin' even if a major error occurs

Reported by nickg | April 22nd, 2010 @ 06:36 PM

I just checked in bad code since ant kept going.
here's an example:
window-spec:

 [echo]
 [echo] Executing Window Spec 
 [java] [  Envjs/1.6 (Rhino; U; Mac OS X x86_64 10.6.3; en-US; rv:

1.7.0.rc2) Resig/20070309 PilotFish/1.2.0.11 ]

 [java]  TypeError: Cannot find function

_updateFormForNamedElement in object [object HTMLHeadingElement].
any hits on how to make this stop hard in this case?
thanks,
--nickg (meanwhile i will fix my code!)

Comments and changes to this ticket

  • gleneivey

    gleneivey April 23rd, 2010 @ 08:07 AM

    I think that this is due to the way that env.js runs client code inside of try{} blocks. I think that this could be "fixed" fairly straight-forward-ly by throwing new exceptions when we catch them, but I don't want to make the change without a consensus on whether we want this behavior all the time or if we want a flag that we can set from tests.

  • gleneivey

    gleneivey May 5th, 2010 @ 09:30 AM

    Another problem I've seen in terms of qUnit failures not being detected/reported by Ant: if a test fails in between a "stop()" call and its following "start()" call, qUnit's test-reporting JavaScript doesn't run, so that number of asserts run isn't verified against expected(), and the RESULTS:/PASSED:/FAILED: summary lines aren't printed. Probably prohibitively difficult to fix within qUnit itself. Perhaps we need some wrapper that Ant can use to invoke each test and scan the results for the summary lines?

  • Steven Parkes

    Steven Parkes May 5th, 2010 @ 12:12 PM

    I remember something like this from a long time ago. If memory serves, you can add a timeout to the stop call, which will cause qunit to automatically restart after the timeout.

    I also vaguely remember looked into making this defaultable so you didn't have to add to every stop.

    I've always thought it would be nice if we could trap errors in async callbacks like timers. I've wondered if it would be legit to call onerror in those cases, but in (limited) browser testing, it appears not.

    We could have an envjs-specific callback. Wouldn't work in the browser, but the point would be to make the test suite run well in the face of errors, which isn't supposed to be the steady state.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

a javascript browser environment

People watching this ticket

Pages