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


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

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 (4 earlier) <ja0t5t$kms$1@speranza.aioe.org> <icWwq.30836$Uw7.17222@newsfe02.iad> <MPG.293310ff31482c2c9896d2@202.177.16.121> <22790268.15.1321806216236.JavaMail.geo-discussion-forums@prgt40> <9e8b681f-055f-4588-9ef6-3702322b4d3e@c4g2000vbh.googlegroups.com>
Message-ID <SAxyq.7213$ov2.4585@newsfe10.iad> (permalink)
Date 2011-11-21 11:25 -0800

Show all headers | View raw


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.


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