[1084] in java-interest
Re: Assertions in Java
daemon@ATHENA.MIT.EDU (Andrew Carlson)
Fri Aug 18 08:37:11 1995
Date: Fri, 18 Aug 1995 09:02:08 +0000
From: andycarlson@attmail.com (Andrew Carlson)
To: java-interest@java.sun.com, johnm@CSUA.Berkeley.EDU (John D. Mitchell)
Hi all,
(See also the recent post from Jeremy Fitzhardinge who makes several
interesting suggestions on this topic, some of which are 'borrowed' here)
John D. Mitchell writes...
>[...if + flag vs assert...]
>Can you think of way to do this without going to the (unpleasant) extreme
>of a pre-processor?
I think there are two approaches: Build it into the language or put it into
the class library. As both language and class library come from the same
place, I would leave such a choice to the originators of java: they are far
better qualified to make such a decision than I am. My main concern is that I
should be able to use asserts elegantly in my code without requiring a
non-standard java environment.
[Interface vs Class Assertions]
>I'll sorta buy that. But can these things be mixed? How/when does an
>interface assertion get called? When for the class one? What are the
>semantics of what happens if they fail? What about side effects? What
>about...
I am no language designer, just a developer with opinions about features which
I consider beneficial in a language. Here's my suggestion:-
On calling a method, invariants, pre and post conditions should be evaluated
in the following order:-
1. Preconditions are evaluated from the top of the inheritance tree downwards.
2. The method inmplementation is executed.
3. Postconditions are evaluated from the bottom of the tree upwards.
4. Invariants are evaluated from the bottom of the tree upwards.
My 'rationale' is to execute the most specific tests closest to the method
implementation. Invariants are essentially method postconditions which apply
to every method (although public attributes (yuck) would mess up this
concept).
As far as side effects and failure semantics go, the C++ ASSERT macro which I
currently use just trashes the entire execution after logging the source file
name and line number which failed. It could be (and has been) suggested that
exceptions might be used to enable an application to catch assertions and
clean up. I think it is important to remember that assertions are for
debugging only when arriving at a decision on this. Their design should not
encourage developers to do things which will make their app break when the
assertions are compiled out of the release version.
The classic mistake is to make a non-query method call inside an assert, which
is compiled out in the release version thus breaking the code (I suppose it
MAY be possible for the language to prevent this, or at least issue a
warning). I suspect that allowing the catching of assertions would open up
more possibilities like this.
>> Everyone presumably agrees that it is possible to describe what an
>> interface method is supposed to do (otherwise documenting the interface
>> would become a pretty difficult exercise). I view the use of invariants
>> and pre/postconditions as an extension of this concept, but in a way
>> which can be enforced by the language.
>I'm dubious that it can be so easily dropped into the language but I'll
>agree in theory. :-)
I didn't say it was going to be easy :-). Seriously, I think the important
factors are (in no particular order):-
1. The mechanism should be fitted into the language in a way which is
'sympathetic' to the existing language design (i.e. it does not make
the language inelegant).
2. The mechanism should be easy for developers to use.
3. The additions to the language should not break existing code.
4. Minimal or no performance overhead in released (i.e. non-debug) code.
One further question now: Will discussion of a topic on this mailing list
result in the consideration of a feature for inclusion in the language, or
must other steps be taken?
Andy.
----------------------------------------------------------------------
Andy Carlson. AT&T ISTEL Tel: +44 1527 494358
E-Mail: andycarlson@attmail.com Fax: +44 1527 494318
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
