Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

if statement that, when false, skips first statement in its block, executes second?

Thread view: 
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 Magazines

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

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.