toward null-safe cookie cutter Comparators

[Lew]

to Lew:
spk *didn't* respond to a posting of Daniel Pitts.

As you're filtering away a lot, you should get into the habit
of NOT-assuming that a followup was always to the preceding
article in your newsclient's display.

You assume a lot yourself, assuming that's what I assumed. It was not.

Nor were filters involved, and I wonder why you thought they were.

Truth is I made a mistake reading the attributions. And it doesn't change the fact that Daniel Pitts is a respected member of this community.

 

[Lew]

thank you kindly.

My error doesn't change the fact that your post, spk, was nothing but trollish crap. Go away unless you're willing to discuss matters related to Java programming.

 

[spk]

My error doesn't change the fact that your post, spk, was nothing
but trollish crap. Go away unless you're willing to discuss matters
related to Java programming.

ummm...for some time now I have entertained the thought you
and derbyshire are joined at the hip.
your original comment is classic derbyshire error as is your reactive
now.
where your broken news client will not filter do not make more noise
whining, consult
http://helpdesk.astraweb.com/index.php

 

[Martin Gregorie]

On Wed, 16 Nov 2011 13:47:57 -0800, Daniel Pitts

[snip]

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.

 

[kensi]

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.

 

[kensi]

Really?

http://www.theregister.co.uk/2008/11/27/myspace_mother_guilty/

Note, she was NOT convicted of "cyber bullying", but of fraudulently
accessing MySpace by providing false personal information. If just goes
to show how useful those "knee-jerk" laws can be, when suitably abused.

That was a HUGE stretch by the prosecution to try to get someone whose
conduct they disliked convicted of *something* even though she hadn't
actually done anything illegal -- and I seem to recall it was thrown out
on appeal.

 

[thoolen]

On Nov 17, 12:40 pm, "spk", an obvious murphy sock, wrote:
NaN> Newsgroups: comp.lang.java.programmer

NaN> One old Derbyshire sock popped a load of hogwash woven under
"kensi"
NaN> <[email protected]>;

Who is "Derbyshire", murphy? There is nobody in this newsgroup using
that alias. And what does your unsubstantiated allegation regarding
kensi have to do with Java, murphy?

NaN> the pedant in you rises again?

What does your question of kensi have to do with Java, murphy?

NaN> you are lost for reason, Paul?

Who is "Paul", murphy? There is nobody in this newsgroup using that
alias.

NaN> How ironic.

I know your trollish posts are ironic, murphy. No need to tell me
about it.

NaN> failing to render "purpose" into the panorama before you, Paul?

Who is "Paul", murphy? There is nobody in this newsgroup using that
alias.

NaN> classic erroneous supposition.

On your part, murphy.

NaN> now just which of Murphy's list are you going to preserve for
CJLP from your
NaN> portfolio of known troll identities?

What does your unsubstantiated allegation of trolling on kensi's part
have to do with Java, murphy? Rather ironic, coming as it does from a
troll, murphy.

NaN> Murphy's list applies;

What does your trademarked Lits o' Haet have to do with Java, murphy?

NaN> Truth in Conclusions.

What does your classic unsubstantiated, erroneous, and ironic claim
have to do with Java, murphy?

NaN> "At some point, can't we find a bit
NaN> of charity for a guy who looks to be in for some real hellish
times up
NaN> ahead?"

How ironic.

What does your URL have to do with Java, murphy?

"I had 'volunteered (years back) to support those who do endeavor
to provide free Free Usenet access, support those who offered
subscription based Free Usenet access, nothing more than
cooperation expected in return for what has been many
thousands of hours of work. I note most of those I joined with
are either deceased, severely disabled, or plain ole' MIA..
now it is my Time. ...

You just read my last. ...

For those who think they see me in future times I can only wish
you severe Tinnitus in your dreams. For those who know me
well (eMail, whatever) and see me, know I will be smiling also.
It is to you I say "adieu mein frenz and adios .. grazie' [hugs]
for all the Good Times! May you and yours always bear well
with all Life brings you".

/0ut"
--murphy

http://www.uffnet.com/kookkamp/goodbye.htm

And some people wonder why I call them Famous Last Words.

 

[thoolen]

On Nov 17, 5:48 pm, "spk", an obvious murphy sock, wrote:
NaN> Newsgroups: comp.lang.java.programmer

NaN> ummm...for some time now I have entertained the thought you
NaN> and derbyshire are joined at the hip.

What does your thought have to do with Java, murphy?

NaN> your original comment is classic derbyshire error as is your
reactive
NaN> now.

Who is "derbyshire", murphy? There is nobody in this newsgroup using
that alias.

NaN> where your broken news client will not filter do not make more
noise
NaN> whining, consult

What does your classic erroneous presupposition have to do with Java,
murphy? Lew posted via Google Groups rather than using any news client
at all, murphy.

What does your URL have to do with Java, murphy?

"I had 'volunteered (years back) to support those who do endeavor
to provide free Free Usenet access, support those who offered
subscription based Free Usenet access, nothing more than
cooperation expected in return for what has been many
thousands of hours of work. I note most of those I joined with
are either deceased, severely disabled, or plain ole' MIA..
now it is my Time. ...

You just read my last. ...

For those who think they see me in future times I can only wish
you severe Tinnitus in your dreams. For those who know me
well (eMail, whatever) and see me, know I will be smiling also.
It is to you I say "adieu mein frenz and adios .. grazie' [hugs]
for all the Good Times! May you and yours always bear well
with all Life brings you".

/0ut"
--murphy

http://www.uffnet.com/kookkamp/goodbye.htm

And some people wonder why I call them Famous Last Words.

P.S. You forgot to include a copy of your trademarked Lits o' Haet,
murphy. Still suffering from memory problems, murphy?

 

[thoolen]

On 18/11/2011 6:20 AM, murphy pretended to be Joe Attardi and wrote:
NaN> Newsgroups: comp.lang.java.programmer

NaN> \\\\

What does that have to do with Java, murphy?

NaN> Do tell me why it is I am coaxed to give your post airtime?

What does your question of Bloch have to do with Java, murphy?

NaN> Perhaps you can persuade there is not an element of "hear me I
NaN> be a self managed mannered masturbator", in your words...?...

What does your ridiculous question of Bloch have to do with Java, murphy?

NaN> which in your head justifies that loss of credible code you so often
NaN> publish?

Classic erroneous presupposition.

NaN> Little attention from us (who do publish) is paid to your titterings
NaN> with your 'confession' now saying more than is needed to reason
NaN> why that is - your meanderings.

Non sequitur.

NaN> As comical as it is to read yet once again the snare you white
NaN> rabbit types find yourself in is as the fact that the trap
NaN> is set by one so plainly transparent (as the tormentor of the
NaN> news group is) is evidence enough once again to never pay
NaN> attention to code redirects posted here.

Non sequitur.

Sign 1 of your forgery: this isn't how Joe Attardi writes, murphy.

NaN> Really it is comical.

What does your comical attempt at a forgery have to do with Java, murphy?

NaN> Get yourself a newsreader...dw33b.

What does your directive to Bloch have to do with Java, murphy?

Sign 2 of your forgery: disliking people who use Google Groups or GUI
newsreaders and demanding they get a newsreader (by which you seem to
mean a text-mode unix newsreader) is a classic murphyism, murphy.

NaN> Lots 0f Fucking Laughter.

What does your foul language have to do with Java, murphy?

Sign 3 of your forgery: foul language is much more characteristic of you
than it is of Attardi, murphy.

What does your URL have to do with Java, murphy?

Sign 4 of your forgery: howardknight URLs are a characteristic murphyism
and they are almost never seen except in your posts, murphy, and quoted
in followups to them.

NaN> In engleze?

What is "engleze", murphy, and what does it have to do with Java?

NaN> PULL YOUR HEAD OOPTA YO ASS!

What does your foul language have to do with Java, murphy?

NaN> Fix the line length, n00B.

Who is "n00B", murphy? There is nobody in this newsgroup using that alias.

"I had 'volunteered (years back) to support those who do endeavor
to provide free Free Usenet access, support those who offered
subscription based Free Usenet access, nothing more than
cooperation expected in return for what has been many
thousands of hours of work. I note most of those I joined with
are either deceased, severely disabled, or plain ole' MIA..
now it is my Time. ...

You just read my last. ...

For those who think they see me in future times I can only wish
you severe Tinnitus in your dreams. For those who know me
well (eMail, whatever) and see me, know I will be smiling also.
It is to you I say "adieu mein frenz and adios .. grazie' [hugs]
for all the Good Times! May you and yours always bear well
with all Life brings you".

/0ut"
--murphy

http://www.uffnet.com/kookkamp/goodbye.htm

And some people wonder why I call them Famous Last Words.

P.S. You forgot to include a copy of your trademarked Lits o' Haet,
murphy. Still suffering from memory problems, murphy?

 

[Daniel Pitts]

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

 

[Lew]

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 theydo, 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 figureout all the places where you stupidly decided to leave out the checks. Noone 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, butyou 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, ordersof magnitude (base 10), cheaper than skipping it and coming back later, inmost cases infinitely cheaper since you'll never get the chance to go backto 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]

static <T> Comparator<T> nullLowComparator(final Comparator<T> delegate)
{
return new Comparator<T>(){
public int compare(final T a, final T b){
return a != null && b != null ? delegate.compare(a,b)
: a == null ? -1
: 1;
}
}
}

So if both 'a' and 'b' are both 'null', it returns -1? That seems problematic - shouldn't it return 0?

I for one would expect 'null' to equal 'null'.

return a == b? 0 : a == null? -1 : b == null? 1 : delegate.compareTo(a, b);

The expression is a little easier if the type implements 'Comparable'.

 

[Daniel Pitts]

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.

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.

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 don't disagree at all.


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


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.


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.

 

[Lew]

Sometimes I doubt that you have worked in a lot of brownfield
projects, because that is far off what I have experienced.

Sorry, "brownfield project"?

I've stepped in a lot of piles, if that's what you mean.

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.

Huh? How does the customer *ever* see an exception? That's a specious argument because you don't let customers see exceptions anyway.

I really don't understand what you're talking about. Checking for null, orhandling null exceptions, has NOTHING whatsoever to do with letting a customer see the exception, because you NEVER let the customer see the exception. That's _why_ you handle it!

Please explain yourself better. I see "prevent exceptions from ruining theprogram" as a mandate to handle them. You apparently see this as a mandate for ignoring them, which is the shortest path to ensuring that the customer sees them. What do I misunderstand here?

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.

I cry "shenanigans" on that pitiful excuse.

I don't disagree at all.


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


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.

Which has nothing to do with trapping and eliminating NPEs. The risk thereis high and the overhead to deal with it is low.

So the decision to ignore the issue and let it reach the customer is not rational.

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".

Sorry, you're mistaken.

"As early as possible" means "not any earlier", so you aren't disagreeing with me.

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.

That's a very colorful description, full of analogy and devoid of engineering content, so I cannot respond except to applaud your imagery.

 

[Gene Wirchenko]

Sorry, "brownfield project"?

GIYF. See
http://igloocoder.com/archive/2007/12/23/what-is-brownfield.aspx
I had not run across the term either, but I see where it would be
useful.

[snip]

Sincerely,

Gene Wirchenko

 

[Lew]

Quoth Lew:

GIYF. See
http://igloocoder.com/archive/2007/12/23/what-is-brownfield.aspx
Thanks.

I had not run across the term either, but I see where it would be
useful.

I'd hazard that makes up about 99% of workaday software development.

 

[Roedy Green]

This pattern, return true if expression is true otherwise carry on is
what I call a "gauntlet", when you have a great string of them in a
row. This pattern came up so frequently in BBL and Abundance I
invented an operator construct for it. (not a dig deal in Forth).

the operator was called ?YES>>>
(>>> means exit, end... in Abundance)

You can't write a Java method that does what it does. You could think
of it as expanding inline like this:

expression ?YES>>>

in Abundance means

if ( expression ) return true ;

Its partner ?NO>>> exited with a false value if the expression were
false.

When you computed a flag. you could have a series of early out
expressions to handle the easy cases.

 

[Arne Vajhøj]

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

 

[Daniel Pitts]

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.

Perhaps, it depends on the project of course, and how many others depend
on you doing your work the way you were told. If you're developing a
library for others to use, and don't do it the way it was designed, then
you've caused problems for many others who were expecting to design
their application one way. On the other hand, if you're developing an
internal tool without interfacing with anyone else, then as long as you
meet the functional requirements, your "internal improvements" shouldn't
be a concern, as long as they are *real* improvements.

It can be a difficult judgement call, but it is sometimes better to
start with the way you think it should be done (especially if it takes
less time to do that), and then "build the bridge" to the way they
wanted it to be done. Building an ugly facade in front of good code is
better than building a pretty facade in front of bad code. Especially
if you're maintaining the code more than the facade.

 

[Arved Sandstrom]

umm.. well actually there is clear recommendation to "fail fast"...

Here is an essay from Martin Fowler's web site explaining quite
eloquently why...

http://martinfowler.com/ieeeSoftware/failFast.pdf

Did you (ilAn) read the very last bit in Jim Shore's PDF, where he talks
about global exception handlers in production? *This* is what Wanja was
getting at, and I myself espouse this approach also.

"Fail fast" means not attempting to handle a problem that cannot be
handled at runtime. No catch-all exception handlers, no dubious
defaults. Be aware of what cannot be handled (configuration file not
found, unexpected NPE, etc) and pass it up immediately to a global
exception handler and either (1) stop the program (development, maybe
test) or (2) stop the individual task and provide help as to what to do
next (production).

Handling locally - what you've misidentified as "fail fast" - is
appropriate only for expected exceptions that can actually be sensibly
handled.

I've helped revamp a number of enterprise web applications to this
global exception handler model, and now rather than users seeing nasty
exception traces or virtually non-reproducible problem behaviour they
get a short but sweet error page that supplies screenshot info they can
paste into the defect tracking system before they call ops support. The
details are also logged.

In order for this system to work - in order for _fail-fast_ to work -
you need to be aggressive about eliminating local catch-all handlers and
poorly conceived automated error handling. "Failure" actually means
visible, unhandled failure. The only acceptable "handling" for an
exception that cannot be handled is to stop that process and provide
enough information for a developer or ops support to fix the problem.

AHS