Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 70955 invoked from network); 21 Oct 2002 15:27:50 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Oct 2002 15:27:50 -0000 Received: (qmail 9225 invoked by uid 97); 21 Oct 2002 15:28:39 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 9215 invoked by uid 97); 21 Oct 2002 15:28:38 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 1746 invoked by uid 98); 21 Oct 2002 14:38:05 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Mon, 21 Oct 2002 09:37:15 -0500 Subject: Re: [Lang] Assertions? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Paul `Order in Chaos` Cantrell To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <98007A7E-E502-11D6-826C-003065BA8D20@pobox.com> X-Mailer: Apple Mail (2.546) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Here's a page explaining 1.4's assertions. I highly recommend reading it -- it will short-circuit a lot of the discussion that Ola's question is bound to generate: http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html JDK 1.4's assertion facilities make most of Ola's examples too trivial to warrant helper methods, IMO -- the following all seem quite clear and concise : assert object != null; assert array.length != 0; assert !coll.isEmpty(); assert str.size() != 0; Note that one can also do this: assert (result != null) : "foo() result is null; expected bar element in" + elements; An assertion utility could, of course, take the string argument: Assert.notNull(result, "foo() result is null; expected bar element in " + elements); However, the Java version has a big advantage: In the latter example, the code will *always* call elements.toString() -- even if the assertion succeeds, and even if assertions are turned off! The Java native version doesn't evalutate the condition unless assertions are enabled, and doesn't evaluate the message unless the assertion fails. The only one of the examples in Ola's message that isn't trivial with 1.4's assert is "noNullElements". If there is actually a need for assert utilities, it's for deeper structural checks like that. What does seem much more generally useful is a hasNullElements() method, which would make the assertion easy to write as a nice side benefit. Henri: Java assertions throw AssertionError. JUnit does provide some basic assertion facilities, but only for test classes. Cheers, Paul On Monday, October 21, 2002, at 09:12 AM, Henri Yandell wrote: > First thoughts on assertion code: > > Does JUnit already have this? What do we feel about JUnits version if > it > does? Does JDK 1.4 contain much more than the 'assert' keyword? > > What does 1.4 throw when an assertion fails? > > Hen > > On Mon, 21 Oct 2002, Ola Berg wrote: > >> How about utilities for assertions? >> >> I can imagine: >> >> class Assert >> notNull( Object) >> noNullElements( Object[]) >> notEmpty( Object[]) //works for collections too >> >> plus either adding methods for common object types: >> >> notEmpty( String) >> >> or adding assert* methods to the lang *Utils: >> >> assertNotEmpty( String) >> >> When an assertion fails, the methods will throw >> IllegalArgumentException >> >> Good or bad? I can do the coding, if people like it. >> >> /O _________________________________________________________________ Paul Cantrell http://eidola.org http://innig.net -- To unsubscribe, e-mail: For additional commands, e-mail: