Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.java.programmer > #4300

Re: About using assertion

Show all headers | View raw

On 05/19/2011 10:41 AM, Robert Klemme wrote:
> On 19 Mai, 15:38, Lew<no...@lewscanon.com>  wrote:
>> On 05/19/2011 09:16 AM, Michal Kleczek wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Lew wrote:
>>
>>>> That is wrong.  That needs to be checked with an 'if' if 'NaN' is not a
>>>> legitimate input.  'assert' is not meant to correct things, only to make
>>>> sure
>>
>>> I totally agree with you.
>>
>>>> that the correction is documented and proven.  If 'assert' is turned off
>>>> in production, you still have the bug if you use 'assert' as the only
>>>> guard.
>>
>>> I was imprecise - just wanted to praise an example of "having confidence"
>>> being sooo wrong and how having assertions (even though they look redundant)
>>> _may_ help you.
>>
>> Totally correct.
>>
>> Assertions are a signpost: HERE THERE BE AN INVARIANT!
>>
>> When subtypes or refactored code violate the invariant, the assertion can help
>> catch it.
>>
>>    public class Foo
>>    {
>>      private Attribute attribute;
>>
>>      public void setAttribute( Attribute attr )
>>      {
>>        if ( attr == null )
>>        {
>>          throw new IllegalArgumentException( "null argument, dummy" );
>>        }
>>        attribute = attr;
>>        assert attribute != null;
>>      }
>>
>>      public Attribute getAttribute()
>>      {
>>        assert attribute != null;
>>        return attribute;
>>      }
>>    }
>>
>>    public class Bar extends Foo()
>>    {
>>      public void setAttribute( Attribute attr )
>>      {
>>        attribute = attr;

> Sorry for the nitpicking, but this cannot compile unless you make
> "attribute" protected or package visible.  But that in itself would be
> a code smell IMHO.  (Even though Java's std lib uses protected in
> various places.  But that's a completely different topic...)

Good call.

>>      }
>>    }

>> The assertion will help reveal that class 'Bar' violated the invariant.  In
>> production, the 'NullPointerException' (in the logs from 'getAttribute()'
>> clients) will trigger an investigation, which will include enabling assertions
>> for the class that yields the value, and then the invariant checks will help
>> find the problem.

> I think I get your point about the usage of assert here but we might
> find a better example.  In this particular case the NPE would catch
> misbehaved sub class code anyway which must go through setAttribute if
> the member variable remains declared "private" (my preferred
> solution).
>
> How about this as an example using template method pattern.
>
> public abstract class Base {
>    /** Sub classes must override this and return an Attribute
>      * where {@link Attribute#getProperty()} returns something
>      * useful (!= null).
>      * @return an Attribute with Property, not null.
>      */
>    protected abstract Attribute getAttribute();
>
>    /** This is the great algorithm this class is all about. */
>    public void theAlgorithm() {
>      final Attribute at = getAttribute();
>      /* We use individual asserts instead of&&  to easier find the
>       * violated rule. */
>      assert at != null;
>      assert at.getProperty() != null;
>      // now we can start working
>      System.out.println("Now this works: " +
> at.getProperty().getLength());
>    }
> }

My point would've been better made if I'd referred to refactoring instead of 
subclassing.  Your example is better.  I do worry about the use of 'assert' to 
check the invariant without backing logic, OTOH this is a use case where the 
superclass seeks to avoid the overhead of runtime checking when the 
implementor is supposedly following the documentation.  So it's a really good 
example.

Because the method is protected, it's part of the API contract for 'Base', so 
a paranoid author would have put 'if' checks, possibly exceptions into 
'theAlgorithm()'.  But it's only part of the contract for programmers who live 
close to the implementation, so it's perfectly reasonable to insist that the 
subclass handle all the 'if' checks, and that the superclass have just 
'assert' to provide a safety net.  An NPE at the 'println()' call would hint 
to ops to enable assertions, then the problem diagnosis is simple via those 
assertions.

This will now be part of my pedagogical toolkit for explaining 'assert'. 
Thank you.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

About using assertion byhesed <byhesed@gmail.com> - 2011-05-09 07:36 -0700
  Re: About using assertion Robert Klemme <shortcutter@googlemail.com> - 2011-05-09 08:24 -0700
    Re: About using assertion Roedy Green <see_website@mindprod.com.invalid> - 2011-05-09 09:01 -0700
      Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-09 12:11 -0400
        Re: About using assertion Robert Klemme <shortcutter@googlemail.com> - 2011-05-09 22:17 +0200
          Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-09 18:49 -0400
            Re: About using assertion Robert Klemme <shortcutter@googlemail.com> - 2011-05-10 07:23 +0200
            Re: About using assertion Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-10 06:45 -0300
              Re: About using assertion Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-10 13:29 +0000
                Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-10 11:21 -0400
                Re: About using assertion Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-10 16:01 +0000
                Re: About using assertion RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-05-10 17:26 +0100
                Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-10 13:25 -0400
                Re: About using assertion Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-10 21:15 +0200
          Re: About using assertion tmcd@tmcd-p4-linux.austin.tx.us (Tim McDaniel) - 2011-05-19 00:32 -0500
            Re: About using assertion Michal Kleczek <kleku75@gmail.com> - 2011-05-19 08:34 +0200
              Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-19 08:46 -0400
                Re: About using assertion Michal Kleczek <kleku75@gmail.com> - 2011-05-19 15:16 +0200
                Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-19 09:38 -0400
                Re: About using assertion Robert Klemme <shortcutter@googlemail.com> - 2011-05-19 07:41 -0700
                Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-19 11:00 -0400
            Re: About using assertion Patricia Shanahan <pats@acm.org> - 2011-05-19 05:52 -0700
              Re: About using assertion tmcd@tmcd-p4-linux.austin.tx.us (Tim McDaniel) - 2011-05-21 18:37 -0500
                Re: About using assertion Patricia Shanahan <pats@acm.org> - 2011-05-21 19:00 -0700
                Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-22 01:19 -0400
  Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-09 11:35 -0400
  Re: About using assertion markspace <-@.> - 2011-05-09 11:40 -0700
    Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-09 14:53 -0400

csiph-web