You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Hope, Matthew" <Ma...@capitalone.com> on 2003/08/27 10:33:00 UTC

RE: [all] RuntimeExceptions, assertions, and pluggable validation

> Here's a rough idea:
> 
> 
> class AsserterFactory
>     Asserter getAsserter(String name)
> 
> interface Asserter
>     void assertTrue(boolean condition, String message)
> 
>     class Java14Asserter
>         void assertTrue(boolean condition, String message)
>             assert condition : message;
> 
>     class StandardAsserter
>         void assertTrue(boolean condition, String message)
>             if(!condition) {
>                 throw new IllegalArgumentException(message)
>         }
> 
>     class PassiveAsserter
>         void assertTrue(boolean condition, String message) {
>             // Does nothing
>         }


The big problem with this is that the jdk1.4 assert semantics would not hold
for someone using this wrapper. Any expression used to evaluate the boolean
would always be evaluated - thus an expensive operation useful for debug and
test would still occur in production, attempting to retrofit assert style
functionality to older jvm's is useful but there is no real way to achive
the runtime switch on / off costless behaviour.

the best you could hope for would be to do it at compile time with
cumbersome boilerplate

if (AssertFunctionality.isEnabled()) {
AssertFunctionality.assert(expression, message);
}

Really if someone wants asserts they have to bite the bullet and move to
1.4, there will be some people who can't do this but I would think most
would find the effort / cost of moving to 1.4 less than trying to retrofit
an inferior solution. 
Commons logging is an excellent solution because the implementations it
wraps do not require new language constructs just additional API's (a jdk
logging jar could have been released to work on 1.3 albeit with a fair
amount of effort). wrapping a new language construct is IMO counter
productive.

Doing a similar thing with a preprocessor would be a solution but a great
cost (there's a reason it was not brought over with the rest of the C
semantics)

Matt
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.