Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Assertions doubt

 
Kedar Pethe
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How come the following code compiles successfully?


Rule - Assertions require that the second expression must evaluate to a value.
Here, it is creating a new object, but where are we assigning the address of the new object to a reference variable(to hold the value) to satisfy the rule??
Isn't the value lost??
 
Pritish Chakraborty
Ranch Hand
Posts: 91
C++ Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The object won't be referable by a live thread and so is eligible for garbage collection, but that does not change the fact that it is an object still living on the heap.

That is enough to satisfy the compiler. You don't need to be able to refer to the object.

When you read about GC in K&B, 'lost' implied that no live thread could access the object (meaning we couldn't).

But that did not mean that the object was destroyed.
 
Nitish Bangera
Ranch Hand
Posts: 537
Eclipse IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Kedar new Clumsy() would inturn generate a value. It has nothing to do whether the object created is lost or can be referred. Please try and let us know.
 
Pritish Chakraborty
Ranch Hand
Posts: 91
C++ Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now I'm confused Nitish...

I suppose toString() will be called implicitly and the object's unsigned hexadecimal ID of sorts will be printed, in your code.

But does the same happen in assertions?
 
Nitish Bangera
Ranch Hand
Posts: 537
Eclipse IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Its not unsigned hexadecimal ID. Its the hashCode of the object. If there isn't a proper toString(), the Object's toString() prints out the hashCode of the created object.Also, if you want to test it out why not try to run it. Run using java -ea Clumsy.
 
Kedar Pethe
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nitish Bangera wrote:Its not unsigned hexadecimal ID. Its the hashCode of the object. If there isn't a proper toString(), the Object's toString() prints out the hashCode of the created object.Also, if you want to test it out why not try to run it. Run using java -ea Clumsy.


Thanks Nitish!! That helped!
 
gurpeet singh
Ranch Hand
Posts: 924
1
Fedora Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the second form of the assert statment assert exp1 : exp2 where exp1 must evaluate to boolean. the exp 2 gets passed to constructor which returns its string value. the second form is just to provide us extra information as to what went wrong. so in your case when you supplied new clumsy() as exp2 it would call its inherited( or the overridden one) toString method , which will return Clumsy@<hashcode in hexadecimal format>. so whenever assertion is false the message will be returned along with the AssertionError.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic