About Question enthuware.ocpjp.v7.2.1565 :

[leorbarbosa]

I have compiled this question with no errors/warnings.

What do you mean for "Assertions should not have side effects." ??

[admin]

It is explained in the explanation -

3. Should not be used for side effects. For example:    

Code: Select all

public boolean doSomething()    
{     
 ...
}    

public void someMethod()    
{       
   assert doSomething();    
}  

This is not a proper use because here the assertion is used for its side effect of calling of the doSomething() method.

Observe that the method will be invoked only if assertions are enabled. If the method is doing something important, then the application will not function correctly if assertions are disabled. This is not good.

HTH,
Paul.

[pfilaretov]

The right option:

Code: Select all

public void openSocket(int port) {     
   Socket s = //valid code to open socket here     
   ...     
   assert s != null; 
}

The explanation says:

Assertions should be used for:
...
3. Validating post conditions at the end of any method. This means, after executing the business logic, you can use assertions to ensure that the internal state of your variables or results is consistent with what you expect. For example, a method that opens a socket or a file can use an assertion at the end to ensure that the socket or the file is indeed opened.

But why "at the end"? What's the idea? If code to open socket fails for some reason and variable "s" is null, then I got some exception (checked or unchecked) in business logic and won't reach assertion.

[admin]

But why "at the end"? What's the idea? If code to open socket fails for some reason and variable "s" is null, then I got some exception (checked or unchecked) in business logic and won't reach assertion.

How will you check post-conditions before the method is done with its execution? They are called post-conditions precisely because they will hold true only after the method has done its work.
Code may not always result in an exception. It may execute without an exception but yet somehow produce wrong results, for example, due to badly written multi-threaded code. You could use assertions to check for such things at the end of the method. If the assertion fails, you know there is some problem with the code that you need to investigate. That's the whole point of assertions. They produce outputs that illuminate the parts of code that execute successfully (i.e. without exceptions) yet are producing unexpected results.

HTH,
Paul.

[pfilaretov]

That's the whole point of assertions. They produce outputs that illuminate the parts of code that execute successfully (i.e. without exceptions) yet are producing unexpected results.

Thank you, Paul, now got it