Re: A java DEBUG flag

[Cedric Berger <cedric at wireless-networks dot com>]

"Boehm, Hans" wrote:
> 
> I'm still not sure how to do this cleanly.  The problem is not factoring out
> the assertion checking code.  It's that you want to maintain e.g. a counter
> only if debugging is enabled.  

What's wrong with my example:
  - There is a counter (Debugging.openFilesCount)
  - The counter is present only when debugging is enabled

Cedric


Thus you want to conditionally execute
> something with a side-effect, where the condition is evaluated at compile
> time.  Expressions in assertions aren't supposed to have side-effects
> (though I guess that isn't enforced).  There doesn't seem to be another way
> to condition something on whether assertions are enabled.
> 
> You could maintain the added state unconditionally, and hope that the
> compiler recognizes it as dead code if debugging is disabled.  But that's
> often not very realistic.  For example, if I look at some of the code in the
> GC that's covered by #ifdef GC_ASSERTIONS, much of it is already hard to
> prove dead with assertions disabled, and it would be still harder if you had
> to preserve null pointer exceptions.
> 
> Hans
> 
> > -----Original Message-----
> > From: Cedric Berger [mailto:cedric@wireless-networks.com]
> > Sent: Friday, December 29, 2000 10:31 AM
> > To: Boehm, Hans
> > Cc: 'burton@relativity.yi.org'; Brian Jones;
> > java-discuss@sources.redhat.com; classpath@gnu.org
> > Subject: Re: A java DEBUG flag
> >
> >
> >
> > "Boehm, Hans" wrote:
> > >
> > > > This is in the SUN Assertion JSR.
> > > > http://java.sun.com/aboutJava/communityprocess/jsr/asrt_prop.html
> > > >
> > > > ... The documentation is public but we certainly can not
> > > > participate in its
> > > > development because of SUNs *stupid* IP restrictions in the
> > > > JCP.  There are good
> > > > ideas here though and since this stuff will eventually make
> > > > it into JDK 1.4 I
> > > > would say it should eventually belong here.
> > > >
> > > True.  But isn't this an awfully weak proposal?  It doesn't
> > seem to allow me
> > > to cleanly compute additional state that's used only in
> > assertion checking.
> > > I find that I need to do that all the time in order to be
> > able to write
> > > reasonable assertions.  For example, I might explicitly
> > keep track of who
> > > holds a particular lock, so that I can assert that I hold
> > it at some point.
> > > Or I might need to count opened files so that I can assert
> > that I closed
> > > everything I opened in a certain section of code.  Or ...
> > >
> > > Hans
> >
> > Can't you put all this stuff a special debug class to keep
> > things clean?
> > This class will only gets loaded if assertions are enabled!
> >
> > 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());
> >     }
> > }
> >
> > Cedric
> >