GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes why will this block of code never work correctly: Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "why will this block of code never work correctly:" Watch "why will this block of code never work correctly:" New topic
Author

why will this block of code never work correctly:

James McKee
Greenhorn

Joined: Jul 11, 2007
Posts: 29
Set Requests = policyBll.getRequests();
if( Requests != null ) {
System.out.println( "requests before: " + Requests.size() );
policyBll.addRequest( RequestBll );

Set newRequests = policyBll.getRequests();
System.out.println( "requests after: " + newRequests.size() );
boolean moreRequests = newRequests.size() > Requests.size();
assertTrue( "Should be more requests", moreRequests );
}




I know you don't know the background...

Apparently the "assertTrue" would always fail...why?
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Since these are Sets, they should reject duplicates. So is it possible that policyBll.addRequest(RequestBll); is adding a duplicate? What are the sizes being output?


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
James McKee
Greenhorn

Joined: Jul 11, 2007
Posts: 29
this is just a hypothetical question that was posed to me dealing with my system, not actual code
[ August 23, 2007: Message edited by: James McKee ]
Yuriy Zilbergleyt
Ranch Hand

Joined: Dec 13, 2004
Posts: 429
You mean it's a homework problem?

Anyway, your assert statement boils down to "are there more items in new Set than in old Set", when both are in fact the same Set.
[ August 23, 2007: Message edited by: Yuriy Zilbergleyt ]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by James McKee:
this is just a hypothetical question that was posed to me dealing with my system, not actual code...

Well, without more information, it seems most likely to me that the element beng added is a duplicate. If that's true and it shouldn't be, then look at the object's equals method. Beyond that, you could look for problems with the getRequests and addRequest methods. Or maybe the assertTrue method itself has a problem.
Yuriy Zilbergleyt
Ranch Hand

Joined: Dec 13, 2004
Posts: 429
Originally posted by marc weber:

Well, without more information, it seems most likely to me that the element beng added is a duplicate. If that's true and it shouldn't be, then look at the object's equals method. Beyond that, you could look for problems with the getRequests and addRequest methods. Or maybe the assertTrue method itself has a problem.


I have to respectfully disagree

It seems far more likely to me that policyBll has a single Requests set that is returns through the getRequests() call. The addRequest() merely adds the RequestBil object to the that set. In other words, Requests == newRequests, so 'newRequests.size() > Requests.size()' is the same as ' newRequests.size() > newRequests.size()'. It will never be true.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Yuriy Zilbergleyt:
...I have to respectfully disagree

It seems far more likely to me that policyBll has a single Requests set that is returns through the getRequests() call...

I think you're right. I made a (really) bad assumption that a new Set was being created with the call to getRequests(). Your explanation does seem more likely.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
If policyBill was coded defensively, the getRequests() method might return a new Set every time - a copy of its private Set. That would prevent any other class from modifying the private Set. Relying on assumptions is a dangerous game. Even relying on today's implementation - say you check and find it is the same set twice - is dangerous because policyBill might get paranoid one day and change how it works.

It's frightening to think of all the ways you can introduce bugs. How could you put more behavior inside policyBill and avoid writing risky logic in this method?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Stan James:
... Relying on assumptions is a dangerous game...

Yeah, confirming what you think you know can be a good troubleshooting technique.
Rory Lynch
Ranch Hand

Joined: Aug 03, 2007
Posts: 95
Is that "beginners" level?

If so I must be sub-beginner


I wish that for just one time, you could stand inside my shoes.<br />You'd know what a drag it is to see you.
 
GeeCON Prague 2014
 
subject: why will this block of code never work correctly: