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

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

Re: toward null-safe cookie cutter Comparators

Show all headers | View raw

In article <2113828.215.1321914010550.JavaMail.geo-discussion-
forums@prlm15>, lewbloch@gmail.com says...

> >> 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.
> 
> Sorry, "brownfield project"?  
> 
> I've stepped in a lot of piles, if that's what you mean.

Greenfield: Program is started on a green field, aka "white piece of 
paper", compromised mainly by time and money. Lots of possibilities to 
to do things right from the start. I love those, but am rarely involved 
in them.

Brownfield: Program is old and already used and there's a project to 
enhance it, usually some heavy refactoring is badly needed, but 
customers are hard to persuade that refactoring is actually a benefit. 
So you have to somehow cope with the creeps that you find inside it. 
Compromised not only by time and money but also the fear to break 
anything that already works. The bigger the program and the user base, 
the worse is the sponsor's fear.
It gets especially worse if there are for or five teams running it, who 
see everything from their own perpective, which could well be some old 
COBOL host code, some PL/SQL, an application server, a Swing client and 
some web interface for some parts, so there is a shitload of different 
Java APIs to move data from A to B. The question "is null a legal value 
or not" is a common thing when talking between subsystems and those 
decisions use to ripple through the whole code base.
 
> > 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.

Well, I know several Applications that allow the user to see a general 
failure message popping up (in case of an exception) and allow him to 
send the error message to the the support (usually containing the 
exception). Among them are clients for investment counseling, insurances 
and the retail system of an international huge home-depot like chain.
The application won't crash entirely though, but the user's current 
changes are lost, which is good, because you don't want half baked 
rubbish polluting the database.

Apart from this: Windows crash logs are nothing hugely different.

> I really don't understand what you're talking about. 

Well, that is obvious.

> Checking for null, or handling 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!

Welcome to the real world, something you might well have yet to 
encounter.

> Please explain yourself better.  
> I see "prevent exceptions from ruining the program" 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?

Software technology.
An Exception is not always a critical error, but if it is and you can't 
recover safely (which is for example if some subsystem delivers "null" 
where a value is expected that cannot be replaced by anything of sense, 
caused by some bad data has made it into the data base or a query has a 
bug, people make mistakes you know), then the user has to be informed 
that something is wrong and it is usually a good idea to provide some 
technical information that he can send to the support, so the bug can be 
fixed. Yes, I have seen systems that automatically log exceptions into a 
database and aggregate them, still they will inform the user that 
something went wrong - and an error message caused by an exception is 
nothing else than an exception in disguise.

> > > 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.
> 
> I cry "shenanigans" on that pitiful excuse.

Well, I guess you have been involved in more or less playground projects 
yet, otherwise I can*t really understand how you have a) the time to 
react to almost every thread in this newsgroup and b) have a so naive 
view.
 
> > > 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.
> 
> Which has nothing to do with trapping and eliminating NPEs.  The risk there is 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.

It is, highly rational. Trapping an NPE is only one side of the story, 
the other is "how to recover" from it. Sometimes this is not possible.
Any major program I have been involved in had a central exception 
handling mechanism as last resort, that put out a user message and 
closed whatever workflow that has caused the exception. Sometimes it's 
the best choice to let the exception bubble up to this point instead of 
trying to fix something that you cannot fix.
Take for example a query for some business transasaction like a purchase 
order and because of some error in the program that data is corrupted: 
instead of finding a "supplier" object, you find "null". What would you 
do? Silently add a new blank supplier? WRONG! Checking for null and put 
out a message window saying "Sorry, the data is corrupted". RIGHT. You 
can try to do this on any case you might expect "null", but the program 
is a whole lot more readable when you just let the exception bubble up 
and handle most of them higher up the call stack.

> > > 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".
> 
> Sorry, you're mistaken.
> 
> "As early as possible" means "not any earlier", so you aren't disagreeing with me.

I am. "As early as possible" means for example: You expect a price and 
you find "null". "As early as possible" would mean that right there 
where you do the get you check for "null" or catch an NPE and do 
something, but "where best handled" is probably higher up the call 
stack, that depends.
 
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 ---

Back to comp.lang.java.programmer | Previous | Next — Previous 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