commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scolebou...@btopenworld.com
Subject Re: [Lang] Assertions?
Date Mon, 21 Oct 2002 15:39:37 GMT
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 <ola.berg@ports.se>
> --->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.
> 
> <random-tought>
> Assertions as a runtime property will render a lot of the use-cases for assertions useless...
I wonder why they did this?
> </random-tought>
> 
> /O
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message