Java Forum / General / January 2006
if statement that, when false, skips first statement in its block, executes second?
Jay McGavren - 14 Jan 2006 21:35 GMT `I've got some very strange behavior here involving an if statement which, when false, skips the first statement in its block, but then *executes the second*! I'm hoping I've made some mistake which will be obvious to someone in the group, that I just haven't noticed yet.
Here's output from a jdb session (my comments preceded with "*"):
*The if statement is about to be evaluated: main[1] list 54 Iterator conditions = conditionIterator(); 55 boolean conditionFailed = false; //If behavior has no conditions, it should be performed by default. 56 conditionLoop: while (conditions.hasNext()) { 57 Condition condition = (Condition) conditions.next(); 58 => if (condition.isMet((GameObject) subject, (GameObject) object) == false) { 59 conditionFailed = true; 60 break conditionLoop; 61 } 62 } 63 *As you can see, it *should* evaluate to false: main[1] print condition.isMet((GameObject) subject, (GameObject) object) condition.isMet((GameObject) subject, (GameObject) object) = true main[1] next
Step completed: "thread=main", net.sourceforge.zyps.Behavior.perform(), line=60 bci=44 *And yet, here it is ready to execute the *second* statement *in the if block! (Even though it skipped the first!) 60 break conditionLoop;
main[1] list 56 conditionLoop: while (conditions.hasNext()) { 57 Condition condition = (Condition) conditions.next(); 58 if (condition.isMet((GameObject) subject, (GameObject) object) == false) { 59 conditionFailed = true; 60 => break conditionLoop; 61 } 62 } 63 64 //Process all actions. 65 Iterator actions = actionIterator();
JDB was run with the command: jdb -classpath build;test_build;C:\junit\junit.jar -sourcepath source;test net.sourceforge.zyps.BehaviorTest
Full source can be accessed here: Behavior: http://cvs.sourceforge.net/viewcvs.py/zyps/zyps/source/net/sourceforge/zyps/Beha vior.java?rev=1.4&view=auto BehaviorTest (probably not relevant): http://cvs.sourceforge.net/viewcvs.py/zyps/zyps/test/net/sourceforge/zyps/Behavi orTest.java?rev=1.4&view=auto Entire source tree: http://cvs.sourceforge.net/viewcvs.py/zyps/zyps/
If anyone has any ideas, they would be most appreciated!
Matt Humphrey - 14 Jan 2006 22:19 GMT > `I've got some very strange behavior here involving an if statement > which, when false, skips the first statement in its block, but then > *executes the second*! I'm hoping I've made some mistake which will be > obvious to someone in the group, that I just haven't noticed yet. > > Here's output from a jdb session (my comments preceded with "*"): <snip code / jdb trace>
In my experience, when I have observed a debugger jumping to the wrong statements (especially around ifs, whiles, etc) it's usually because I changed the source code and forgot to recompile / redeploy and I'm seeing the old code execution with the new source lines.
Cheers, Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/
Jay McGavren - 14 Jan 2006 23:10 GMT Matt Humprey wrote:
> In my experience, when I have observed a debugger jumping > to the wrong statements (especially around ifs, whiles, > etc) it's usually because I changed the source code and > forgot to recompile / redeploy and I'm seeing the old code > execution with the new source lines. Unfortunately, this is a fresh compile. (And this problem has persisted for a week through multiple compilations on both Windows and Linux.) I'm certainly willing to believe that my compiled code and my source aren't "aligned" correctly, but I don't know how to rectify that...
I'm compiling via Ant, BTW. Here's the task:
<target name="compile" depends="initialize" description="Compile the source"> <javac srcdir="${source_directory}" destdir="${build_directory}" debug="on"> <classpath refid="project.class.path"/> <!-- <compilerarg value="-Xlint:unchecked"/> --> </javac> </target>
http://cvs.sourceforge.net/viewcvs.py/zyps/zyps/build.xml?rev=1.2&view=auto
Roedy Green - 14 Jan 2006 23:44 GMT >`I've got some very strange behavior here involving an if statement >which, when false, skips the first statement in its block, but then >*executes the second*! Errors of this sort can be avoided by these rules:
1. always enclose if and else bodies in { }. Beware particularly the construction if () if ()
2. Check for ; after if (); it should not be there. If you really mean it write:
/* do nothing */ ;
instead.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
opalpa@gmail.com opalinski from opalpaweb - 15 Jan 2006 03:07 GMT Neither one applies here Roedy.
Re: 1
There is only one if, so nested if statements are not an issue. Also, a note, Kernighan writes if statements without braces.
Re: 2
It's not there.
---
Sometimes compilers implement breaks and continues wrong. There was one time when AT&T's telephone network, about twenty five years back, went down cause a break from a switch was implemented wrong in compiler. Anyway, looks like a bug; perhaps rewrite the code? I believe this code could be written more idiomatically. Idioms rarely, if ever, compile wrong.
Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/
Roedy Green - 15 Jan 2006 09:20 GMT On 14 Jan 2006 19:07:51 -0800, "opalpa@gmail.com opalinski from opalpaweb" <opalpa@gmail.com> wrote, quoted or indirectly quoted someone who said :
>There is only one if, so nested if statements are not an issue. Also, >a note, Kernighan writes if statements without braces. and it is a dangerous practice for newbies.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Thomas Hawtin - 15 Jan 2006 16:28 GMT > On 14 Jan 2006 19:07:51 -0800, "opalpa@gmail.com opalinski from > opalpaweb" <opalpa@gmail.com> wrote, quoted or indirectly quoted > someone who said : > >>There is only one if, so nested if statements are not an issue. Also, >>a note, Kernighan writes if statements without braces. Famous as a C programmer who writes compressed code with lots of symbols, undescriptive identifiers and little compiler support. Hopefully most of us have left that sort of stuff behind.
> and it is a dangerous practice for newbies. It's a dangerous practice for anyone.
I once spent a day or two trying to optimise an embedded system in order to get a half-decent sound quality. Then I noticed a stray semicolon at the end of a {}less if().
Tom Hawtin
 Signature Unemployed English Java programmer http://jroller.com/page/tackline/
Roedy Green - 15 Jan 2006 22:21 GMT On Sun, 15 Jan 2006 16:41:27 +0000, Thomas Hawtin <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone who said :
>I once spent a day or two trying to optimise an embedded system in order >to get a half-decent sound quality. Then I noticed a stray semicolon at >the end of a {}less if(). I would like it if there were a lint option to insist on {} for if and no empty statements. Algol 68 had "nihil" when you wanted an explicit empty statement. If's without them look so innocent but do things so different from what they first appear.
I can stare at the code for 10 minutes and still not see the problem.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Jay McGavren - 15 Jan 2006 22:45 GMT Everyone, thanks for the advice, but it now appears as if this is a case of jdb inaccurately reporting which line it is about to execute. I placed an executable line following the if block, thusly:
conditionLoop: while (conditions.hasNext()) { Condition condition = (Condition) conditions.next(); if (! condition.isMet((GameObject) subject, (GameObject) object)) { conditionFailed = true; break conditionLoop; } System.out.println("foobar"); }
...and when the if statement was false, it then reported that the line it was about to execute was the println (instead of the break). A check of the variable values suggests that no code within the if block was ever executed.
I think I'm starting to see why very few people use jdb. When I have time, I'm going to try out the Eclipse debugger instead. (I also intend to make this code a little cleaner.) Thanks for the advice, everyone!
Alan Krueger - 16 Jan 2006 17:49 GMT > I think I'm starting to see why very few people use jdb. When I have > time, I'm going to try out the Eclipse debugger instead. (I also > intend to make this code a little cleaner.) Thanks for the advice, > everyone! This may not go away with Eclipse, as I've seen related (but not identical) things there. These strange debugger jumps are usually due to the way the generated code is structured and how it interacts with the line number information.
Chris Smith - 15 Jan 2006 16:38 GMT > On 14 Jan 2006 19:07:51 -0800, "opalpa@gmail.com opalinski from > opalpaweb" <opalpa@gmail.com> wrote, quoted or indirectly quoted [quoted text clipped - 4 lines] > > and it is a dangerous practice for newbies. Not just for newbies...
 Signature www.designacourse.com The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
Alan Krueger - 16 Jan 2006 16:02 GMT > Sometimes compilers implement breaks and continues wrong. There was > one time when AT&T's telephone network, about twenty five years back, > went down cause a break from a switch was implemented wrong in > compiler. The one 16 years ago in 1990 was apparently due to a coding error involving a misplaced break, not a compiler error. Did they have another catastrophic network crash before that?
http://www.cs.berkeley.edu/~nikitab/courses/cs294-8/hw1.html
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|