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

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

Re: toward null-safe cookie cutter Comparators

Show all headers | View raw

In article <m262hnfqca.fsf@email.com>, nosuch@email.com says...

> > 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.
> 
> Yes I did. I was not sure that was what Wanja was getting at...
> 
> Is it Wanja?

It is, but as so often it depends.

> It seemed Wanja was saying that the codebase he/she is working with
> nulls are commonly passed around if data was not "correct"; potentially
> causing a null pointer exception somewhere else in the codebase... and
> then just throwing that null pointer; and not catching it as early as
> possible and replacing it with an Exception that contains some state
> information and context for that Null Pointer.
> 
> Wanja, did I misunderstand you?

Let me explain it this way:
If you take "fail fast" very, very seriously you end up with "design by 
contract", which in Java means plastering your sourcecode with 
preconditions, postconditions and invariant-checks in every method. I've 
tried that on a private project, and it sucks, so it is not what I would 
recommend anyone to do. The code was full of checks and one could hardly 
tell the serious from the not-so-serious checks and the purpose of the 
code from the checks and most of the effort was wasted time. It meant 
that whenever I refactored out a method, I had to add postcondition, 
preconditions and invariant-checks to it, even though I knew that a 
certain parameters could bot be wrong, since the calling code was just 4 
lines up in the source code, was the only one to call that method and 
had guard clauses itself and the method was dead simple. Later I 
restricted that to public methods and even that did not satisfy me, 
since I like to write unit tests. I had to recognize that the 
postconditions of the public API and some invariants are pretty well 
checked by unit tests, so there is hardly any need to repeat that on the 
source itself, plus the code looks cleaner this way. 
So what's left were post-conditions and some invariant checks and I 
still won't plaster all my source code with guard clauses in every 
method, since that still clutters up my code and cause in repeated 
tests. 
As a rule of thumb, I don't have guard conditions in private methods, 
except of course, the method is a more complex guard condition check.
So what's left is guard conditions in public APIs, and still I have 
progressed in not writing them on every method.
I have found it much better to generally code everything as if the data 
was okay, which narrows down the code to it's sole purpose and makes it 
more readable. And at some points, that I find important, for example 
where I expect bad data could cause havoc or where I don't trust the 
data source like the API of a public service, fields in a form and so 
on, where I find that providing additional information is vital to find 
an error, I will check for bad data and create an exception that 
contains some context for debugging. Usually you would find most of that 
in the I/O-sections of my code and more commonly in the input sections.

What I will not do, and do not reccommend anyone to do, is try to fix 
bad data or work around it by skipping code or using some self-chosen 
default. It might add stability on some cases, but it will most 
certainly cause your program to fail in unexpected situations, where the 
root of the problem is hard to trace, mess up your database with corrupt 
data, et cetera.
I have seen situations where bad data in the database stopped an 
application from running, because it caused mayhem in the event 
dispatching thread. We could have added a "just display an empty field 
if this is stupid" to the renderer, but what we did was to introduce a 
sanity check at the access layer boundary, that failed when reading bad 
data, so the whole invoice could not be opened until we had fixed that 
problem on the database well enough to let the customer re-enter the 
correct data from his print-outs. We also ran a check on the database 
for other cases of this problem, had him correct those, identified the 
cause and corrected it (hint: you don't want to override hashcode and 
equals in  business objects stored in databases).

By the way: It is a pitty that stack traces don't contain the parameters 
on the stack.

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