Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 90710 invoked from network); 21 Oct 2002 15:40:14 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Oct 2002 15:40:14 -0000 Received: (qmail 22897 invoked by uid 97); 21 Oct 2002 15:41:01 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 22866 invoked by uid 97); 21 Oct 2002 15:41:00 -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 22849 invoked by uid 98); 21 Oct 2002 15:40:59 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <2075836.1035214777843.JavaMail.root@127.0.0.1> Date: Mon, 21 Oct 2002 16:39:37 +0100 (BST) From: scolebourne@btopenworld.com To: commons-dev@jakarta.apache.org Subject: Re: [Lang] Assertions? Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-MAILER: talk21.com WAS v2 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Exactly. The Assert class we are talking about here is validating the arguments - passed into a public API - at runtime - from an untrusted source (our user's code!) - throwing IAE in case of error I have a class like this at both work (called Assert) and in the Joda project (called Validate). IMO, the name validate is less overloaded, so I would favour that. This is a very useful class ;-) Stephen > from: Ola Berg > --->8--- > * Do not use assertions for argument checking in public methods. > > Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException). An assertion failure will not throw an appropriate exception. > > * Do not use assertions to do any work that your application requires for correct operation. > > Because assertions may be disabled, programs must not assume that the boolean expression contained in an assertion will be evaluated. > ---8<--- > > The use of Assert (or whatever) I thought of would be precisely that illegal use: to faciliate argument checking in public methods (and throw IAE), in order to enforce object contracts. If it is easy to enforce a contract, more people will enforce their contracts better and the amount of stable code in the world will increase. > > > Assertions as a runtime property will render a lot of the use-cases for assertions useless... I wonder why they did this? > > > /O > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: