Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


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

Re: toward null-safe cookie cutter Comparators

From Daniel Pitts <newsgroup.nospam@virtualinfinity.net>
Newsgroups comp.lang.java.programmer
Subject Re: toward null-safe cookie cutter Comparators
References <hkuvb758inpkqmju7aeeln2nab28i0aue6@4ax.com> <alpine.DEB.2.00.1111131750140.19917@urchin.earth.li> <onl2c7hnvjaogv8ulhti0ius9hei4ce3mp@4ax.com>
Message-ID <kudwq.20012$am1.18958@newsfe05.iad> (permalink)
Date 2011-11-14 10:55 -0800

Show all headers | View raw


On 11/14/11 10:28 AM, Roedy Green wrote:
> On Sun, 13 Nov 2011 17:59:54 +0000, Tom Anderson
> <twic@urchin.earth.li>  wrote, quoted or indirectly quoted someone who
> said :
>
>> return aSpecies.compareTo( bSpecies );
>>
>> Perhaps even pushing the duplicated denullification into a little method.
>> Note that when the Elvis operator makes it into Java, you will be able to
>> write:
>
> This whole business of multiple representations for empty.
> Acch(Imagine a Yiddish sound of contempt).
>
> null, "", "     "
>
> I have have always felt this looseness was like a trap a child digs to
> catch the mailman.
>
> There are no assertions defining what a given method parm will accept
> (though IntelliJ is pushing @Nullable and #NotNull)  There is not even
> a JavaDoc convention to warn you if a method might produce which
> combinations of the three.
>
> see http://mindprod.com/jgloss/empty.html
>
>  From a machine efficiency point of view, null is probably the best
> convention. Empty is usually a special case anyway. It might as well
> be easy to detect.
>
>  From a coding safety point of view "" is best.  It will generaly work
> sensibly if passed to a method expecting a substantial string, where
> there is a good chance it would fail on null.
The real problem is handling User Input and Form Submission. The empty 
string ("") signifies that a field was submitted but not filled with any 
value.  A null value signifies that the field was not submitted at all.

Unfortunately when processing such forms the null value, an empty 
string, and an all whitespace string, usually need to be treated the 
same way. Invalid input.

The truth of the matter is that should all be handled by the 
binding/validation layer, and then normalized to exactly one such value 
(possibly null).  Often they should be converted to a domain object 
anyway, rather than kept as "just a string".
>
> Maybe we need some sort of Generics to declare what methods
> produce/consume and have thecompiler  tell you if you are potentially
> doing something dangerous at compile time.
>
> I once drove my boss nearly to distraction, because I was convinced
> the problem with the project was random empty string representations.
I've seen projects where a *core* library had a method "isNull" defined 
thusly:

public boolean isNull(Object o) {
    if (o == null) return true;
    String s = String.valueOf(o);
    if (s.trim().length == 0) {
       return true;
    }
    if ("null".equals(s)) return true;
    if ("(null)".equals(s)) return true;
}

Obviously, someone was told that "null" and "(null)" were appearing 
somewhere and causing problems. Instead of tracking down the source, 
they littered the codebase with these "isNull" checks. I should have my 
legal name changed to "Null Null", and see how many forms on the web 
reject my name :-)
>
> The DWIM school of thinking
>
> Way back I wrote suggesting a DWIM approach to taming the dreaded
> NullPointerException.  It is inspired more by scripting languages.
>
> Thing a = null.
>
> a.getAString()  -->  null
> a.getTemp() -->  0.0d;
> a.getDufusOBject -->  null
>
> a.doSomething() -->  does nothing
>
> a.doSomethingElse ( engage( 42 ) ); -->  invokes engage function
>    ( in my mind checking a and store come after RHS evaluation,
>     If I had my way Java would a much stricter  left to right
> evaluation order)
>
NPE is one of the best things that can happen. It tells you immediately 
what needed to have a value but didn't.  Rather than the end result of a 
chain of null operations that failed deeply in the project.

Imagine the following:

// Commonly used library method handleThing.
void handleThing(Thing t) {
    AnotherThing at = t.getAnotherThing()
    doSomething(at);
}

void doSomething(AnotherThing t) {
    saveToDatabase(t.getName(), t.getId());
}

Now, imagine you get a database error (or worse, no error, just bad null 
records). You have *no* trace whatsoever of which call of handleThing 
caused the problem. This is similar to the potential problem caused by 
NaN propagation.

> For more explicit use, you would replace the . operator with .? to
> indicate you wanted to do a dummy var fetch/method call or none at all
> if "a" were null.  When I thought about extending that I though
> perhaps classes should use dummy objects in place of null to bypass
> this sort of trouble at clealr all that null-handling clutter,just
> letting the null-handling  logic come out in the wash most of the
> time.
>
> The thinking is a bit like the way there are are multiple flavours of
> NaN in IEEE floating point, and the value appearing in calculation is
> not the end of the world. The null just propagates.
>
> P.S.
> Apparently the eponymous Elvis rarely went to Las Vegas. I have not
> tracked down who he is.  People were often puzzled when I talked about
> the McCarthy or operator || the bitwise | one.
> see http://mindprod.com/jgloss/or.html  The McCarthy I refer to
> probably never met Candice Bergen and died recently.

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


Thread

toward null-safe cookie cutter Comparators Roedy Green <see_website@mindprod.com.invalid> - 2011-11-13 09:17 -0800
  Re: toward null-safe cookie cutter Comparators Tom Anderson <twic@urchin.earth.li> - 2011-11-13 17:59 +0000
    Re: toward null-safe cookie cutter Comparators Roedy Green <see_website@mindprod.com.invalid> - 2011-11-14 10:28 -0800
      Re: toward null-safe cookie cutter Comparators Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-14 10:55 -0800
        Re: toward null-safe cookie cutter Comparators Roedy Green <see_website@mindprod.com.invalid> - 2011-11-15 09:04 -0800
        Re: toward null-safe cookie cutter Comparators kensi <kensi_kensington@zoonoses.de> - 2011-11-16 12:50 -0500
          Re: toward null-safe cookie cutter Comparators Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-16 13:47 -0800
            Re: toward null-safe cookie cutter Comparators Gene Wirchenko <genew@ocis.net> - 2011-11-16 16:09 -0800
              Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-16 17:02 -0800
                Re: toward null-safe cookie cutter Comparators Gene Wirchenko <genew@ocis.net> - 2011-11-16 17:31 -0800
              Re: toward null-safe cookie cutter Comparators Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-17 22:51 +0000
            Re: toward null-safe cookie cutter Comparators Paul Cager <paul.cager@googlemail.com> - 2011-11-17 02:43 -0800
              Re: toward null-safe cookie cutter Comparators Tim Slattery <Slattery_T@bls.gov> - 2011-11-17 08:57 -0500
              Re: toward null-safe cookie cutter Comparators Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-18 16:05 -0800
            Re: toward null-safe cookie cutter Comparators kensi <kensi_kensington@zoonoses.de> - 2011-11-17 21:21 -0500
            Re: toward null-safe cookie cutter Comparators Wanja Gayk <brixomatic@yahoo.com> - 2011-11-20 13:29 +0100
              Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-20 08:23 -0800
                Re: toward null-safe cookie cutter Comparators Brixomatic <wanja.gayk@googlemail.com> - 2011-11-21 04:39 -0800
                Re: toward null-safe cookie cutter Comparators Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-21 11:25 -0800
                Re: toward null-safe cookie cutter Comparators Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:44 -0500
                Re: toward null-safe cookie cutter Comparators Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-26 15:34 -0800
                Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-21 14:20 -0800
                Re: toward null-safe cookie cutter Comparators Gene Wirchenko <genew@ocis.net> - 2011-11-21 19:22 -0800
                Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-21 22:45 -0800
                Re: toward null-safe cookie cutter Comparators Wanja Gayk <brixomatic@yahoo.com> - 2011-12-10 12:15 +0100
                Re: toward null-safe cookie cutter Comparators ilAn <idonot@wantspam.net> - 2011-12-10 19:47 +0200
                Re: toward null-safe cookie cutter Comparators Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-10 14:57 -0400
                Re: toward null-safe cookie cutter Comparators ilAn <nosuch@email.com> - 2011-12-11 10:46 +0200
                Re: toward null-safe cookie cutter Comparators Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-12 07:42 -0400
                Re: toward null-safe cookie cutter Comparators ilAn <nosuch@email.com> - 2011-12-12 16:06 +0200
                Re: toward null-safe cookie cutter Comparators "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-12-13 02:01 +1100
                Re: toward null-safe cookie cutter Comparators Wanja Gayk <brixomatic@yahoo.com> - 2011-12-17 12:30 +0100
                Re: toward null-safe cookie cutter Comparators Wanja Gayk <brixomatic@yahoo.com> - 2011-12-17 12:30 +0100
            Re: toward null-safe cookie cutter Comparators Roedy Green <see_website@mindprod.com.invalid> - 2011-11-22 19:47 -0800
          Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-16 14:02 -0800
            Re: toward null-safe cookie cutter Comparators Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-17 08:42 +0000
          Re: toward null-safe cookie cutter Comparators Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-11-17 15:09 +0000
            Re: toward null-safe cookie cutter Comparators kensi <kensi_kensington@zoonoses.de> - 2011-11-17 21:22 -0500
          Re: toward null-safe cookie cutter Comparators spk <jhic@speak.invalid> - 2011-11-17 13:40 -0400
            Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-17 09:56 -0800
              Re: toward null-safe cookie cutter Comparators spk <jhic@speak.invalid> - 2011-11-17 14:00 -0400
                Re: toward null-safe cookie cutter Comparators Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-17 19:23 +0000
                Re: toward null-safe cookie cutter Comparators spk <jhic@speak.invalid> - 2011-11-17 16:35 -0400
                Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-17 13:50 -0800
                Re: toward null-safe cookie cutter Comparators spk <jhic@speak.invalid> - 2011-11-17 18:48 -0400
                Re: toward null-safe cookie cutter Comparators thoolen <tholen01@gmail.com> - 2011-11-17 18:33 -0800
                Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-17 13:48 -0800
                Re: toward null-safe cookie cutter Comparators "Joe Attardi" <jattard1@gmail.com> - 2011-11-18 12:20 +0100
                Re: toward null-safe cookie cutter Comparators thoolen <th00len@th0lenbot.thorium> - 2011-11-18 15:21 -0500
            Re: toward null-safe cookie cutter Comparators thoolen <tholen01@gmail.com> - 2011-11-17 18:31 -0800
    Re: toward null-safe cookie cutter Comparators Wanja Gayk <brixomatic@yahoo.com> - 2011-11-20 13:14 +0100
      Re: toward null-safe cookie cutter Comparators Lew <lewbloch@gmail.com> - 2011-11-20 08:29 -0800
        Re: toward null-safe cookie cutter Comparators Brixomatic <wanja.gayk@googlemail.com> - 2011-11-21 04:03 -0800

csiph-web