This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Public methods are used by lot of other people and you dont want the method to behave differently depending on the arguments passed (and behave differently would be due to the wrong use of asserts- like suppressing the actual exceptions). The Public method (and not asserts) should check for wrong arguments being passed and throw exceptions if any wrong arguments are passed.
Private methods- its under the control of the creator and he knows exactly how and where the method is being used. That way he knows what arguments are being passed to it.
Long time I read about them, someone might be able to correct me or add to it.
In my opinion there's nothing wrong with using asserts in public methods, too. The point here is, that "assert" can be enabled/disabled with a simple command line flag of the JVM. So you CAN use them to make some assertions for preconditions, postconditions etc. during the test phase of an application but the logic of your code should definitely NOT depend on asserts. That means asserts can be used in public methods as additional assertions but they should not be used for regular parameter validation and something like taht because they could simply be deactivated at runtime.
I understood that assert is only to be used during debugging or testing. What i didnt understand is why they are recommending that i should use assert when debugging private methods but not when debugging public methods.
Its true that public methods are used by other people and i dont have control of what is passed into the public method. Just because i have control of the private method it doesnt mean that i wont make a mistake. Since i will be debugging/testing both the public or private methods i dont see how it would make a difference.
Since i will be debugging/testing both the public or private methods i dont see how it would make a difference.
The difference is that you document some assumptions you made when you wrote the code for a method. For example if you decided that some (private) method should not be called with null as parameter value (under normal conditions) it's OK to have no null checks in this method because it simply expects that parameters should not be null when the method is used correctly. That's were asserts are a good way to document such assumptions inside the code itself.
But it's NOT ok to use asserts to validate input parameters for public methods because you simply cannot (always) contol what the caller of a method will give you as a parameter value. You should make the necessary checks with the usual Java tools but don't depend on asserts for your logic to work correctly. But it's fine to have asserts besides the regular check mechanism.
Marco Ehrentreich wrote: it's OK to have no null checks in this method because it simply expects that parameters should not be null when the method is used correctly
Wrong, you should ALWAYS check the preconditions in public methods. Assertions must be explicitly enabled, hence you can't rely on them for validating public methods as they'll be probably called by other people. You can use them to validate your private methods, you enable them during testing to make sure that you're using your methods correctly, once tested you don't need the extra checks...