Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why will this block of code never work correctly:

 
James McKee
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
James McKee
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 429
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 429
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is that "beginners" level?

If so I must be sub-beginner
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic