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

Groups > comp.lang.java.programmer > #9917 > unrolled thread

toward null-safe cookie cutter Comparators

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#9917 — toward null-safe cookie cutter Comparators

I don't know how many people still subscribe, but I posted over in
comp.lang.advocacy a request on your preferred way of writing
null-safe Comparators.

I have shown a number of possible snippets. Please let me know what
you think and see if you can come up with something better -  fast,
terse and comprehensible.

I will incorporate the feature in the CompatorCutter for cranking out
Java source code for custom Comparators.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet. 

[toc] | [next] | [standalone]

#9925

On Sun, 13 Nov 2011, Roedy Green wrote:

> I don't know how many people still subscribe, but I posted over in 
> comp.lang.advocacy a request on your preferred way of writing null-safe 
> Comparators.

Roedy means (a) comp.lang.java.advocacy, and (b) comparators for objects 
some of whose fields may be null (ie i don't think he's concerned with 
comparators where one of the arguments may be null).

For those of you who are into Google Groups, the other thread is here:

http://groups.google.com/group/comp.lang.java.advocacy/browse_thread/thread/83db33bcbd51905d#

Approaches involving nested if-elses will be more efficient, but always 
strike me as rather awkward.

> I have shown a number of possible snippets. Please let me know what you 
> think and see if you can come up with something better - fast, terse and 
> comprehensible.

I personally rather like your third option:

final String aSpecies = a.species == null ? "" : a.species;
final String bSpecies = b.species == null ? "" : b.species;
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:

return (a.species ?: "").compareTo(b.species ?: "");

Should you so wish.

I'm also happy to see:

if (a.species == b.species) return 0;

as a guard clause ahead of the main comparison, which catches, as you say, 
both the both-null and identical-objects cases.

tom

-- 
No man ever steps in the same river twice, for it's not the same river
and he's not the same man. -- Heraclitus

[toc] | [prev] | [next] | [standalone]

#9959

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.

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.

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)

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.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet. 

[toc] | [prev] | [next] | [standalone]

#9960

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.

[toc] | [prev] | [next] | [standalone]

#9965

On Mon, 14 Nov 2011 10:55:11 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

>>
>NPE is one of the best things that can happen

I  really enjoyed that post.  It might have been composed by Mark
Twain were he a computer programmer.

Amen. One of the almost miraculous things about Java is once you get
rid of the compile errors, and once you stop triggering NPEs, there
very good chance you have nailed all the bugs.

There are situations where null is expected and it is just a hassle to
explicitly deal with it, and other places where its presence is a sign
of pathology.  

Whatever changes you make to the language should not make you treat
everything the same way.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet. 

[toc] | [prev] | [next] | [standalone]

#9978

On 14/11/2011 1:55 PM, Daniel Pitts wrote:
> 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;
> }

Shocking, if true, since the above code won't compile.

> 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 :-)

Why go to the hassle of changing your legal name? It's not like giving 
false information to large corporate marketing departments^W^W^W^Wweb 
forms is an offense under the law or anything. ;) At most it's a TOS 
violation and the account you create won't last long (cf. Facebook, 
Google Plus).

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

Comment above is wrong, should be
// Commonly used Law of Demeter violation
HTH. :)

[toc] | [prev] | [next] | [standalone]

#9983

On 11/16/11 9:50 AM, kensi wrote:
> On 14/11/2011 1:55 PM, Daniel Pitts wrote:
>> 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;
>> }
>
> Shocking, if true, since the above code won't compile.
Well, I did "copy and paste" from memory, and my clipboard is obviously 
fallible.  There should be a "return false;" immediately prior the final 
"}".
>
>> 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 :-)
>
> Why go to the hassle of changing your legal name? It's not like giving
> false information to large corporate marketing departments^W^W^W^Wweb
> forms is an offense under the law or anything. ;) At most it's a TOS
> violation and the account you create won't last long (cf. Facebook,
> Google Plus).
Because if I change my legal name, then I have legal recourse for them 
discriminating against me ;-).
>
>> Imagine the following:
>>
>> // Commonly used library method handleThing.
>> void handleThing(Thing t) {
>> AnotherThing at = t.getAnotherThing()
>> doSomething(at);
>> }
>
> Comment above is wrong, should be
> // Commonly used Law of Demeter violation
> HTH. :)

Perhaps in this case, but the point still stands that null propagation 
can make bug diagnosis much more difficult.

[toc] | [prev] | [next] | [standalone]

#9988

On Wed, 16 Nov 2011 13:47:57 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

[snip]

>> Why go to the hassle of changing your legal name? It's not like giving
>> false information to large corporate marketing departments^W^W^W^Wweb
>> forms is an offense under the law or anything. ;) At most it's a TOS
>> violation and the account you create won't last long (cf. Facebook,
>> Google Plus).
>Because if I change my legal name, then I have legal recourse for them 
>discriminating against me ;-).

<perry mason>
     "Your Honour, we have documented proof in writing of the
defendant's intent to commit computer hacking.  Exhibit A is a name
change application that the defendant ..."

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9990

Gene Wirchenko wrote:
> Daniel Pitts wrote:
> [snip]
> 
> >> Why go to the hassle of changing your legal name? It's not like giving
> >> false information to large corporate marketing departments^W^W^W^Wweb
> >> forms is an offense under the law or anything. ;) At most it's a TOS
> >> violation and the account you create won't last long (cf. Facebook,
> >> Google Plus).
> >Because if I change my legal name, then I have legal recourse for them 
> >discriminating against me ;-).
> 
> 
> 
>      "Your Honour, we have documented proof in writing of the
> defendant's intent to commit computer hacking.  Exhibit A is a name
> change application that the defendant ..."
> 
> [snip]

Cute, but given that Daniel's approach involves no login to any computer systems, no coding, no scripting nor any other computer activity of his own, it would be very difficult indeed to make a case that he's engaging in computer hacking.  In fact, he would make such a change with no certain knowledge that computer systems have a weakness, much less any demonstrable attempt to exploit such weakness.

http://xkcd.com/327/

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9992

On Wed, 16 Nov 2011 17:02:34 -0800 (PST), Lew <lewbloch@gmail.com>
wrote:

>Gene Wirchenko wrote:
>> Daniel Pitts wrote:
>> [snip]
>> 
>> >> Why go to the hassle of changing your legal name? It's not like giving
>> >> false information to large corporate marketing departments^W^W^W^Wweb
>> >> forms is an offense under the law or anything. ;) At most it's a TOS
>> >> violation and the account you create won't last long (cf. Facebook,
>> >> Google Plus).
>> >Because if I change my legal name, then I have legal recourse for them 
>> >discriminating against me ;-).

>>      "Your Honour, we have documented proof in writing of the
>> defendant's intent to commit computer hacking.  Exhibit A is a name
>> change application that the defendant ..."
>> 
>> [snip]
>
>Cute, but given that Daniel's approach involves no login to any computer
 systems, no coding, no scripting nor any other computer activity of
his own, it would be very difficult indeed to make a case that he's
engaging in computer hacking.  In fact, he would make such a change
with no certain knowledge that computer systems have a weakness, much
less any demonstrable attempt to exploit such weakness.

     Well, he might be typing into some system.

     "Your Honour, the defendant's lawyer is obviously trying to get
his client off on a technicality.  This is tantamount to admitting
guilt."

>http://xkcd.com/327/

     Spoilsport.  <BEG>

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10023

On Wed, 16 Nov 2011 16:09:17 -0800, Gene Wirchenko wrote:

> On Wed, 16 Nov 2011 13:47:57 -0800, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net> wrote:
> 
> [snip]
> 
>>> Why go to the hassle of changing your legal name? It's not like giving
>>> false information to large corporate marketing departments^W^W^W^Wweb
>>> forms is an offense under the law or anything. ;) At most it's a TOS
>>> violation and the account you create won't last long (cf. Facebook,
>>> Google Plus).
>>Because if I change my legal name, then I have legal recourse for them
>>discriminating against me ;-).
> 
> <perry mason>
>      "Your Honour, we have documented proof in writing of the
> defendant's intent to commit computer hacking.  Exhibit A is a name
> change application that the defendant ..."
>
Something similar happened in real life in Australia during the late '70s.

A natural anarchist, name of Ivor Stowe, heard that the federal tax 
system had a validation rule to exclude surnames of less than two 
letters, so promptly changed his legal name to Ivor H. I knew Ivor - he 
was a most interesting character. 

I can't remember what the effect was though: presumably the tax system 
was changed to require at least one letter in a surname.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#9999

On Nov 16, 9:47 pm, Daniel Pitts
<newsgroup.nos...@virtualinfinity.net> wrote:
> >> 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 :-)
>
[...]
> Because if I change my legal name, then I have legal recourse for them
> discriminating against me ;-).

Reminds me of: http://xkcd.com/327/

[toc] | [prev] | [next] | [standalone]

#10000

Paul Cager <paul.cager@googlemail.com> wrote:

>On Nov 16, 9:47 pm, Daniel Pitts
><newsgroup.nos...@virtualinfinity.net> wrote:
>> >> 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 :-)
>>
>[...]
>> Because if I change my legal name, then I have legal recourse for them
>> discriminating against me ;-).
>
>Reminds me of: http://xkcd.com/327/


ROTFL!!!!

-- 
Tim Slattery
Slattery_T@bls.gov
http://members.cox.net/slatteryt

[toc] | [prev] | [next] | [standalone]

#10059

On 11/17/11 2:43 AM, Paul Cager wrote:
> On Nov 16, 9:47 pm, Daniel Pitts
> <newsgroup.nos...@virtualinfinity.net>  wrote:
>>>> 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 :-)
>>
> [...]
>> Because if I change my legal name, then I have legal recourse for them
>> discriminating against me ;-).
>
> Reminds me of: http://xkcd.com/327/

Yes, that actually was part of my inspiration for the comment ;-)

[toc] | [prev] | [next] | [standalone]

#10024

On 16/11/2011 4:47 PM, Daniel Pitts wrote:
> On 11/16/11 9:50 AM, kensi wrote:
>> Comment above is wrong, should be
>> // Commonly used Law of Demeter violation
>> HTH. :)
>
> Perhaps in this case, but the point still stands that null propagation
> can make bug diagnosis much more difficult.

I agree about your larger point.

[toc] | [prev] | [next] | [standalone]

#10093

In article <icWwq.30836$Uw7.17222@newsfe02.iad>, 
newsgroup.nospam@virtualinfinity.net says...

> Perhaps in this case, but the point still stands that null propagation 
> can make bug diagnosis much more difficult.

Even though I do second you on that, reality says: You rarely have a 
chance to avoid null propagation and null checks, because you can't 
write everything for yourself, not every project is a greenfield project 
and sometimes leaving a null somewhere is the quick option that your 
project lead is willing to pay (think of partially populating models in 
several steps for example).

Kind regards,
-Wanja-

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#10098

On Sunday, November 20, 2011 4:29:30 AM UTC-8, Wanja Gayk wrote:
> In article <icWwq.30836$Uw7.17222@newsfe02.iad>, 
> newsgrou...@virtualinfinity.net says...
> 
> > Perhaps in this case, but the point still stands that null propagation 
> > can make bug diagnosis much more difficult.
> 
> Even though I do second you on that, reality says: You rarely have a 
> chance to avoid null propagation and null checks, because you can't 
> write everything for yourself, 

So what you're saying is that you can only maintain code to which you have access to the source code.  Frikkin' brilliant.

> not every project is a greenfield project 
> and sometimes leaving a null somewhere is the quick option that your 
> project lead is willing to pay (think of partially populating models in 
> several steps for example).

That is pure horseshit, a stinky, steaming, stellar pile of it.

First of all, my project lead doesn't tell me to skip null checks.  If they do, I ignore them.  If they insist, I tell them to stuff it.  What a ridiculous concept.

How unprofessional can one be?

A 'NullPointerException', like other runtime exception, evidences a programming error.  You just spoke up in favor of deliberately programming bugs into the code.  Stupid, stupid idea.  Please do not work on any project I care about.

The overhead of checking data validity (e.g., non-null inputs to a method) is far, far lower when first coding then it is later when you try to figure out all the places where you stupidly decided to leave out the checks.  No one who knows software development should be so stupid as to suggest deliberately increasing the cost and reducing the correctness of a program like that.

Good managers work to reduce risk and cost.

The point is that you catch such exceptions as early as possible.  DUHHH, of course you can't catch it in the middle of some third-party API call, but you can catch it the moment that call returns to your code, and that's what was recommended to limit exception propagation.  Pinning it to third-party code suffices, so your point was specious.

The cost of writing the checks up front is orders of magnitude, yes, orders of magnitude (base 10), cheaper than skipping it and coming back later, in most cases infinitely cheaper since you'll never get the chance to go back to correct your stupidly deliberate mistakes.

So let's push back on idiotic, stupid suggestions like, "Let's make the program correct later - just get it done incorrectly for now."

What a maroon!

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10146

On 20 Nov., 17:23, Lew <lewbl...@gmail.com> wrote:
> On Sunday, November 20, 2011 4:29:30 AM UTC-8,WanjaGayk wrote:
> > In article <icWwq.30836$Uw7.17...@newsfe02.iad>,
> > newsgrou...@virtualinfinity.net says...
>
> > > Perhaps in this case, but the point still stands thatnullpropagation
> > > can make bug diagnosis much more difficult.
>
> > Even though I do second you on that, reality says: You rarely have a
> > chance to avoidnullpropagation andnullchecks, because you can't
> > write everything for yourself,
>
> So what you're saying is that you can only maintain code to which you have access to the source code.  Frikkin' brilliant.

This and that programming an API that loves "null" can force you to
create a lot of unnecessary ingenious ways to avoid "null" as much as
possible, cluttering up your sourcecode, while you could also try to
just manage the problem.

> > not every project is a greenfield project
> > and sometimes leaving anullsomewhere is the quick option that your
> > project lead is willing to pay (think of partially populating models in
> > several steps for example).
>
> That is pure horseshit, a stinky, steaming, stellar pile of it.
>
> First of all, my project lead doesn't tell me to skipnullchecks.  If they do, I ignore them.
> If they insist, I tell them to stuff it.  What a ridiculous concept.

Sometimes I doubt that you have worked in a lot of brownfield
projects, because that is far off what I have experienced.
I've had numerous situations where I discussed an issue and was told
to: "Just do it the simple way" or "not cause an Exception, but return
no result instead", because the customer would not complain as much.
As a programmer I hate it, but life is no walk in the park.

> How unprofessional can one be?

> A 'NullPointerException', like other runtime exception, evidences a programming error.
> You just spoke up in favor of deliberately programming bugs into the code.  Stupid, stupid
> idea.  Please do not work on any project I care about.

Reality is that I dislike to deliberately introduce a bug to my code,
but that sometimes people get forced to do so. That said: A bug is a
bug, whether it's an NPE or another kind of failure in the program.
NPEs are often easier to track down, that's why I favor them. Alas it
is not always my decision.

> The overhead of checking data validity (e.g., non-nullinputs to a method) is far, far lower when first coding then it is later when you try to figure out all the places where you stupidly decided to leave out the checks.

I don't disagree at all.

>  No one who knows software development should be so stupid as to suggest deliberately increasing the cost and reducing the correctness of a program like that.

No one "should" but reality is: Some are.

> Good managers work to reduce risk and cost.

Not everyone is a good manager but that said: Good managers aren't
dogmatic either. If the risk is low and the cost is great, a good
manager may rightfully decide to take the risk.

> The point is that you catch such exceptions as early as possible.

Wrong! Absolute rubbish, sorry. You catch exceptions where best
handled and that may well be further up the call stack. It always
depends on the situation, there is no such golden hammer for exception
handling like "as early as possible".

I tend to treat the exception handling mechanism as an alternative
execution path that has preferably one destination, not a series
potholes fixed with small nets to tumble over fall into and crawl out
again while running backwards until finally giving up or recovering
somewhere. If it crashes, I tend to let it bubble up to a point where
I see a good way to handle it, that also avoid clutter.

Kind regards,
Wanja

[toc] | [prev] | [next] | [standalone]

#10160

On 11/21/11 4:39 AM, Brixomatic wrote:
> On 20 Nov., 17:23, Lew<lewbl...@gmail.com>  wrote:
>> On Sunday, November 20, 2011 4:29:30 AM UTC-8,WanjaGayk wrote:
>>> In article<icWwq.30836$Uw7.17...@newsfe02.iad>,
>>> newsgrou...@virtualinfinity.net says...
>>
>>>> Perhaps in this case, but the point still stands thatnullpropagation
>>>> can make bug diagnosis much more difficult.
>>
>>> Even though I do second you on that, reality says: You rarely have a
>>> chance to avoidnullpropagation andnullchecks, because you can't
>>> write everything for yourself,
>>
>> So what you're saying is that you can only maintain code to which you have access to the source code.  Frikkin' brilliant.
>
> This and that programming an API that loves "null" can force you to
> create a lot of unnecessary ingenious ways to avoid "null" as much as
> possible, cluttering up your sourcecode, while you could also try to
> just manage the problem.
Null propagation itself isn't the problem.  Unexpected null propagation 
is.  Null in itself isn't a bad value, and sometimes has useful meanings 
(as you point out, API's that love null).

The problem comes when the result of operating on a null is another null 
at the language level.  This causes bad data to propagate from an 
unknown source.

>
>>> not every project is a greenfield project
>>> and sometimes leaving anullsomewhere is the quick option that your
>>> project lead is willing to pay (think of partially populating models in
>>> several steps for example).
>>
>> That is pure horseshit, a stinky, steaming, stellar pile of it.
>>
>> First of all, my project lead doesn't tell me to skipnullchecks.  If they do, I ignore them.
>>   If they insist, I tell them to stuff it.  What a ridiculous concept.
>
> Sometimes I doubt that you have worked in a lot of brownfield
> projects, because that is far off what I have experienced.
> I've had numerous situations where I discussed an issue and was told
> to: "Just do it the simple way" or "not cause an Exception, but return
> no result instead", because the customer would not complain as much.
> As a programmer I hate it, but life is no walk in the park.
Exceptions should be used appropriately.  Customers will complain less 
if your exception is well documented and designed, rather than deal with 
a method that returns potentially bunk data.
>
>> How unprofessional can one be?
>
>> A 'NullPointerException', like other runtime exception, evidences a programming error.
>> You just spoke up in favor of deliberately programming bugs into the code..  Stupid, stupid
>> idea.  Please do not work on any project I care about.
>
> Reality is that I dislike to deliberately introduce a bug to my code,
> but that sometimes people get forced to do so. That said: A bug is a
> bug, whether it's an NPE or another kind of failure in the program.
> NPEs are often easier to track down, that's why I favor them. Alas it
> is not always my decision.
It is often easier to beg forgiveness than beg permission.  "It wasn't 
my decision to code this bug" is a cop-out.  Yes, in the past I've had 
to code things differently than I thought best.  I was very junior. 
Once I got over that and started doing things *my* way (disobeying 
direct orders), I began to rise in the ranks.

Note, I did things my way, not because I didn't understand why they 
wanted it the other way, but because I understood the consequences of 
both approaches.

>
>> The overhead of checking data validity (e.g., non-nullinputs to a method) is far, far lower when first coding then it is later when you try to figure out all the places where you stupidly decided to leave out the checks.
>
> I don't disagree at all.
>
>>   No one who knows software development should be so stupid as to suggest deliberately increasing the cost and reducing the correctness of a program like that.
>
> No one "should" but reality is: Some are.
>
>> Good managers work to reduce risk and cost.
>
> Not everyone is a good manager but that said: Good managers aren't
> dogmatic either. If the risk is low and the cost is great, a good
> manager may rightfully decide to take the risk.
>
>> The point is that you catch such exceptions as early as possible.
>
> Wrong! Absolute rubbish, sorry. You catch exceptions where best
> handled and that may well be further up the call stack. It always
> depends on the situation, there is no such golden hammer for exception
> handling like "as early as possible".
>
> I tend to treat the exception handling mechanism as an alternative
> execution path that has preferably one destination, not a series
> potholes fixed with small nets to tumble over fall into and crawl out
> again while running backwards until finally giving up or recovering
> somewhere. If it crashes, I tend to let it bubble up to a point where
> I see a good way to handle it, that also avoid clutter.
"as early as /possible/" is another way of saying "as early as there is 
a good way to handle it".

I think you both said the same thing, with different words.  The real 
point isn't about catching the problems, but signalling the problem as 
soon as possible.

[toc] | [prev] | [next] | [standalone]

#10252

On 11/21/2011 2:25 PM, Daniel Pitts wrote:
> On 11/21/11 4:39 AM, Brixomatic wrote:
>> On 20 Nov., 17:23, Lew<lewbl...@gmail.com> wrote:
>>> A 'NullPointerException', like other runtime exception, evidences a
>>> programming error.
>>> You just spoke up in favor of deliberately programming bugs into the
>>> code.. Stupid, stupid
>>> idea. Please do not work on any project I care about.
>>
>> Reality is that I dislike to deliberately introduce a bug to my code,
>> but that sometimes people get forced to do so. That said: A bug is a
>> bug, whether it's an NPE or another kind of failure in the program.
>> NPEs are often easier to track down, that's why I favor them. Alas it
>> is not always my decision.
> It is often easier to beg forgiveness than beg permission. "It wasn't my
> decision to code this bug" is a cop-out. Yes, in the past I've had to
> code things differently than I thought best. I was very junior. Once I
> got over that and started doing things *my* way (disobeying direct
> orders), I began to rise in the ranks.
>
> Note, I did things my way, not because I didn't understand why they
> wanted it the other way, but because I understood the consequences of
> both approaches.

I will not recommend that strategy as a career move.

In a lot of places developers disobeying direct orders because
they think they know better will be kicked out immediately.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web