Caution You should never use assertions to validate the inputs on public methods—these are methods that other programmers may use, and they may not honor your requirements. You should validate these inputs regardless of whether or not assertions are turned on at runtime.
Alex Dragoi, SCJP 1.4, OCPJP 6
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
Alex Dragoi, SCJP 1.4, OCPJP 6
Alexandru Dragoi wrote:Thanks for the feedback K. Tsang!
I just started to document myself and read books regarding OCMJD and I think that JavaRanch forum is a great resource to learn.
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
K. Tsang wrote:Looking at Andrew's assertion example, it has a problem. The assert statement is checked after it has deducted the withdrawal amount. Instead a better version may look something like
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
Sresh Rangi wrote:Checking the balance after makes sense if it's not possible for the balance to be negative. For example, reduceBalance checks the balance itself and throws an exception if there are insufficient funds. This way the program doesn't rely on assertions for correct behavior. They are only used for documentation or testing.
Assertions aren't normally used on parameters because the method can not make any guarantees of what values they have.
Alex Dragoi, SCJP 1.4, OCPJP 6
Alexandru Dragoi wrote:However, I would prefer a checked exception (instead of a runtime IllegalArgumentException/IllegalStateException) to be thrown if the validation fails. That is because if the user tries to withdraw an invalid amount, this should be a recoverable condition and not a programming error.
Roel De Nijs wrote:
Alexandru Dragoi wrote:However, I would prefer a checked exception (instead of a runtime IllegalArgumentException/IllegalStateException) to be thrown if the validation fails. That is because if the user tries to withdraw an invalid amount, this should be a recoverable condition and not a programming error.
Throwing a checked exception when this validation fails is of course even better. But you always have to be careful when using checked exceptions: when used thoughtless they can clutter your code in no time, certainly when you are designing/creating a framework/library/API. And as already mentioned in my previous post: I used IllegalArgumentException/IllegalStateException to guarantee correct use of the API as possible. So that's to prevent a developer of abusing the API, when it goes wrong it's not a recoverable condition, the developer just mad a mistake. The exception which is thrown when a room/contractor is already booked, is definitely a checked exception.
Alex Dragoi, SCJP 1.4, OCPJP 6
Alexandru Dragoi wrote:So it will be up to the client of the API who calls this method to perform the actual validation.
Alex Dragoi, SCJP 1.4, OCPJP 6
Alexandru Dragoi wrote:Now regarding JSONObject, it looks horrible! And they cannot even change the API without breaking their clients code.
JSONObject seems to be doomed forever!
Alex Dragoi, SCJP 1.4, OCPJP 6
Talk sense to a fool and he calls you foolish. -Euripides A foolish tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|