3 Replies Latest reply: Oct 28, 2006 1:28 PM by 796440 RSS

    Not null declaration keyword

    843853
      Hi, I think there is a lot of messy code in JDK, and the most of it is done checking the null references. So I suggest use some keyword in declaration of methods.

      See an example:
      public class Foo
      {
      
      private final String text;
      private final Object obj;
      
      public Foo ( final String text, final Object obj )
      {
      
      if ( text == null )
      throw new NullPointerException ("text");
      if ( obj == null )
      throw new NullPointerException ("obj");
      
      this.text = text;
      this.obj = obj;
      
      }
      
      }
      and with use of notnull keyword:
      public class Foo
      {
      
      private final String text;
      private final Object obj;
      
      public Foo ( notnull final String text, notnull final Object obj )
      {
      
      this.text = text;
      this.obj = obj;
      
      }
      
      }
      I mean, there could be some compile-time check and some run-time check for reflection api, which will be responsible for throwing NullPointerException with name of argument.

      Sorry for my English ;-)
        • 1. Re: Not null declaration keyword
          796440
          I mean, there could be some compile-time check
          The compiler can't know if the value passed to a method will be null. The value is determined at runtime.

          and
          some run-time check for reflection api, which will be
          responsible for throwing NullPointerException with
          name of argument.
          We already have that (except for the name of the argumet): Just don't check for null, and if it's null, an NPE will be thrown. The null checks are there specifically to avoid an NPE.
          • 2. Re: Not null declaration keyword
            843853
            We already have that (except for the name of the
            argumet): Just don't check for null, and if it's
            null, an NPE will be thrown. The null checks are
            there specifically to avoid an NPE.
            I believe the OP is referring to the understandable desire to detect null as early at runtime as possible. For example, to throw an exception at construction time of an object, rather than at a later point when a method is called and the field is actually accessed. I think the idea has some merit actually; not that an explicit check and throw is that much effort, but it would be pretty expressive (and encourages defensive coding) to be able to declare an argument as "expected never to be null" in the signature. This is a limited form of the broader idea of expressing preconditions with a dedicated syntax, but it is so recurringly desirable that it's worth its own... annotation probably. If such a mechanism existed in Java, I would use it as often as I do an explicit null check in especially ctor arguments (in fact, I wouldn't mind it being the default actually).
            On a sidenote, I do think it's wrong to throw an NPE in this situation; IllegalArgumentException is more appropriate.
            • 3. Re: Not null declaration keyword
              796440
              Ah, I see.

              Well, I guess that could be useful.

              If it were implemented, however, I'd rather see it as a special case or a more general precondition mechanism.

              e.g.
              void foo(notnull Bar bar) {
                  // body
              }
              
              would be shorthand for something like
              
              void foo(Bar bar) {
                  pre {
                      bar != null : IllegalArgumentException;
                  }
              } 
              In the pre block, you could put whatever boolean expressions you want, and the exception to throw if they're not met.

              But yeah, I don't find I spend a lot of time writing
              if (bar == null) {
                  throw new IllegalArgumentException();
              } 
              Nor do I typically have a whole lot of checks for arguments' validity cluttering up my code. So I don't see that much benefit in this (unlike, say, the enhanced for loop).