Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!feeder.news-service.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: About using assertion Date: Tue, 10 May 2011 07:23:42 +0200 Lines: 67 Message-ID: <92s0f4F16fU1@mid.individual.net> References: <09cb7d90-9b79-473e-9869-4476c5a0191a@w24g2000yqb.googlegroups.com> <92r0e9F6lvU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net BNquJusYdaonkUywZtT/NQPiE8Bd4VENei5P3einS+V+S+nZA= Cancel-Lock: sha1:3c/FTiL/4BeskVJSAs+iofCS6bs= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 In-Reply-To: X-Antivirus: avast! (VPS 110509-1, 09.05.2011), Outbound message X-Antivirus-Status: Clean Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3898 On 10.05.2011 00:49, Lew wrote: > Robert Klemme wrote: >> Lew, I am not sure what you tried to convey with this posting. I for >> my part >> would say that the assert is a tad too much here since the if clause >> before >> that gives me enough "confidence" that arg is actually >= 0 at that >> line. If > > First, the example is deliberately simple to highlight the structural > location for 'assert' statements. Formally, they go where invariants are. > > The exception gives that confidence, yes, but only just now at > code-inspection time. At this level, the assertion provides not much > more than compiler-enforced documentation of the invariant. However, > refactoring, inheritance and other future actions could violate the > invariant. This would manifest in production, where source code is not > immediately convenient. OK, I see what you mean. Only trouble with refactoring (as with any code changes) is that you need to watch out which parts you extract as method. The assert could end in less useful than optimal place. :-) > Ops guys can use assertions to locate which invariants were violated, > helping diagnose and triage the problem. > >> it isn't then I have bigger problems than calculating square roots of >> negative >> numbers. :-) > > True but only at one moment in time. Assertions live ongoingly and can > be re-enabled at trouble time. > >> It's probably a different story if the calculation is done by a >> private method >> in which case I'd probably add the assert to the beginning of that >> method just >> to be sure the caller (which can only be in the same class or nested >> classes) >> did not make a mistake. > > There is art in the decision of which invariants to document. I like to > document all of them. Why not? Others only document a few. Why? I've > been on the ops end of production code quite a few times, so I find > assertions valuable. I studied math way back when, and I appreciate > their formal value. Pragmatically there is no reason to avoid them, and > good reasons to use them liberally, if strategically. Absolutely! As you said: The fact that you can enable and disable them at will *after* compile time is a big plus of Java. > There is no real art to deciding where assertions go if you do use them. > They go at the algorithmic invariant points. I assert that you should > use them wherever they support operations, and in the largest proportion > of invariant points consistent with that goal. That is a matter of your > strategy and style. Thanks for clarifying, Lew! Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/