RE: A java DEBUG flag

["Boehm, Hans" <hans_boehm at hp dot com>]

In this case, I think this is a reasonable way to do things, given the
constraints.  But it contradicts one of the statements in the asserion
proposal:

"Because assertions may be disabled, programs must not assume that the
expressions contained in assertions will be evaluated. Thus, it is extremely
bad practice for these expressions to have any side effects: evaluating the
boolean expression should never affect any state that is visible after the
evaluation is complete. (It is not, in general, possible for the compiler to
enforce a prohibition on side-effects in assertions, so the language
specification does not disallow the practice.) "

Note the middle sentence.

In general, this style doesn't strike me as particularly clean.  Removing
the above paragraph is probably an improvement, but not a complete fix.  If
I read "assert" I expect a predicate, not something that's executed
primarily for effect.  At least for one or two line statements, I also find
things much easier to read if such code is inline, not off in a separate
class.  In this case I have that option (modulo getting rid of the
openFilesCountField), but with more complex actions, I don't.

Hans

> -----Original Message-----
> From: Cedric Berger [mailto:cedric@wireless-networks.com]
> Sent: Friday, December 29, 2000 11:38 AM
> To: Boehm, Hans; java-discuss@sources.redhat.com
> Subject: Re: A java DEBUG flag
> 
> 
> Sorry, I know what's wrong with my example. here is the right one:
> 
> class Debugging {
>     static int openFilesCount;
>     static boolean openFile() {
>         return openFilesCount++ < LIMIT;
>     }
>     static boolean closeFile() {
>         return openFilesCount-- > 0;
>     }
> }
> class Main {
>     void doSomething() {
>         assert(Debugging.openFile());
>         // do something
>         assert(Debugging.closeFile());
>     }
> }
>