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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#10271

On 11/25/11 6:44 PM, Arne Vajhøj wrote:
> 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.

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.

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

#10168

Brixomatic wrote:
> Lew wrote:
>> 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.

> 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, 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!

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?

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

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

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

-- 
Lew

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

#10170

On Mon, 21 Nov 2011 14:20:10 -0800 (PST), Lew <lewbloch@gmail.com>
wrote:

>Brixomatic wrote:
>> Lew wrote:
>>> 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"?

     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

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

#10171

Gene Wirchenko wrote:
> Quoth Lew:
>> Sorry, "brownfield project"?
> 
>      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.

-- 
Lew

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

#10643

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

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

#10648

Wanja Gayk <brixomatic@yahoo.com> writes:

<snip>

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

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

<snip>

>  
> Kind regards,
> Wanja

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

#10649

On 11-12-10 01:47 PM, ilAn wrote:
> Wanja Gayk <brixomatic@yahoo.com> writes:
> 
> <snip>
> 
>>
>>>>> 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".
> 
> 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
> 
> <snip>
> 
>>  
>> Kind regards,
>> Wanja

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

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

#10654

Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:

> On 11-12-10 01:47 PM, ilAn wrote:
>> Wanja Gayk <brixomatic@yahoo.com> writes:

>
> 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 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?

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

You are assuming I have misidentified something. 

But I guess by assuming that, you get a suitable springboard to
reiterate what was in the article. A useful rhetorical trick I suppose.

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

I never suggested otherwise.

In fact why would anyone suggest otherwise? 

You don't need to turn me into a scarecrow to make your arguments and
describe how you revamp enterprise web applications so well. 

I believe you are excellent developer; you don't need to insult me to
prove that.

>
> AHS

--
ilAn

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

#10664

On 11-12-11 04:46 AM, ilAn wrote:
> Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:
> 
>> On 11-12-10 01:47 PM, ilAn wrote:
>>> Wanja Gayk <brixomatic@yahoo.com> writes:
> 
>>
>> 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 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?

As I read it and understood it, the scenario is the very common one of
null value handling, where "null" is a problem value - you cannot
proceed any further on the happy path with it.

Did he flat out advocate re-throwing NPEs? I didn't see that, I saw him
talking about letting them bubble up without catching them at all. The
only thing that would catch them would be a global exception handler
that is looking for NPEs.

On the subject of catching them, and wrapping them in a "more useful"
exception that holds extra context information, that _sounds_ appealing,
but ask yourself always if the complete stack trace for the NPE doesn't
already tell you what you need to know. If not, the tactic of wrapping
with extra information may be appropraite, but then so might be always
logging the potentially offending method call with parameter
information. One size doesn't fit all.

>> "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.
> 
> You are assuming I have misidentified something. 

Well, not assuming, I'm flat out saying it based on your own words. In
your previous response you conflated "fail fast" with "as early as
possible". To be more precise, you apparently think (or thought) that
"fail fast" _identically_ means catching locally.

Catching locally could be one way in which you fail fast. But then so is
a global exception handler - which you'll have seen from Jim Shore's PDF
then requires that you do not _handle_ locally, although you could
certainly catch locally, enhance, and re-throw a wrapper to the global
exception handler.

You could certainly catch locally *and* handle locally, which depending
on what you do in the handling may or may not be "fail fast". If you
attempt to proceed when you oughtn't, that's not fail fast.

> But I guess by assuming that, you get a suitable springboard to
> reiterate what was in the article. A useful rhetorical trick I suppose.

Rhetorical trick? We may have read the same PDF but we sure didn't
understand it the same way. So obviously I felt the need to mention
parts of it.

>> 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.
> 
> I never suggested otherwise.
> 
> In fact why would anyone suggest otherwise? 
> 
> You don't need to turn me into a scarecrow to make your arguments and
> describe how you revamp enterprise web applications so well. 
> 
> I believe you are excellent developer; you don't need to insult me to
> prove that.

No insults intended. Not even in this reply. This is a purely
professional discussion. It's a good and interesting discussion - this
entire topic is one with a great variety of useful perspectives and
opinions and approaches, and it's one of the most important topics in
writing quality software.

AHS

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

#10665

Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:

> On 11-12-11 04:46 AM, ilAn wrote:
>> 
>> You don't need to turn me into a scarecrow to make your arguments and
>> describe how you revamp enterprise web applications so well. 
>> 
>> I believe you are an excellent developer; you don't need to insult me
>> to prove that.
>
> No insults intended. Not even in this reply. This is a purely
> professional discussion. It's a good and interesting discussion - this
> entire topic is one with a great variety of useful perspectives and
> opinions and approaches, and it's one of the most important topics in
> writing quality software.

Ok. But I assure you I did not read the article any differently to you.

But I get the sense that you don't want to believe that; and I am not
going to go grey about your perceptions.

>
> AHS

--
ilAn

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

#10671

"Arved Sandstrom"  wrote in message news:IMlFq.15279$U16.68@newsfe15.iad... 

On 11-12-11 04:46 AM, ilAn wrote:

[snip]

> You don't need to turn me into a scarecrow to make your arguments and
> describe how you revamp enterprise web applications so well. 
> 
> I believe you are excellent developer; you don't need to insult me to
> prove that.

[snip]

Arved, please don't feed the trolls.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]

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

#10822

In article <IMlFq.15279$U16.68@newsfe15.iad>, asandstrom3minus1
@eastlink.ca says...

> On the subject of catching them, and wrapping them in a "more useful"
> exception that holds extra context information, that _sounds_ appealing,
> but ask yourself always if the complete stack trace for the NPE doesn't
> already tell you what you need to know. 

Yep, depends. In eleven years of Java programing I have yet to see the 
golden rule of thumb for these situations. I have seen numerous attempts 
to wrap exceptions in "business exceptions" that tell you that for 
example posting an order could not be accomplished, but they hardly 
added any value because where they were caught or thrown, enough data 
was present to be able to reconstruct the problem.

I have also once tried to create exceptions that you may catch, add 
information, and rethrow, and those were occasionally useful (for 
example in a reporting framework, where I added local coordinates and 
stuff to the exception, so I could tell that layouting did not work, 
because a cell of height 10 was added to a box of height 5 that was at 
position x/y relative to its parent that was on position x/y relative to 
the page, the text was "foo" and of this or that font, etc.). 

But that try/catch/retrow also cluttered up the source code and made me 
believe that there was probably something fundamentally wrong with the 
design of the application. 
I also thought of some AOP-like proxied interfaces that would enrich a 
custom exception bubbling through, alas that would not help with private 
methods or any methodcalls bypassing the proxy because the object calls 
its own methods, which only leaves code intrumentation as a possible, 
clean implementation. I have yet to try that, but to be honest: When I 
come home from work I use to have seen enough code for a day.

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]

#10821

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

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

#10184

On Wed, 16 Nov 2011 13:47:57 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

>>> if ("null".equals(s)) return true;
>>> if ("(null)".equals(s)) return true;
>>> }

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

#9984

kensi wrote:
> 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.

He said, "thusly", not "thus", thus allowing a little room for transcription error, in this case the omission of the catch-all 'return false;'.

His main point, that even with the correction the routine is stupid, is not damaged.

-- 
Lew

> > 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]

#9996

Lew <lewbloch@gmail.com> wrote:
> kensi wrote:
>> 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.
> He said, "thusly", not "thus", thus allowing a little room
> for transcription error, in this case the omission of the
> catch-all 'return false;'.

Funny. The missing parens after length caught my eye, but
the missing return at the end didn't. :-)

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

#10001

On 16/11/11 17:50, kensi wrote:
> 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).

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.

-- 
Nigel Wade

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

#10025

On 17/11/2011 10:09 AM, Nigel Wade wrote:
> On 16/11/11 17:50, kensi wrote:
>> 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).
>
> 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.

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

#10007

One old Derbyshire sock popped a load of hogwash woven under "kensi"
<kensi_kensington@zoonoses.de>;

>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.
>
the pedant in you rises again?

>> 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? 
>
you are lost for reason, Paul?
How ironic.

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

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

>At most it's a TOS >violation and the account you create won't 
>last long (cf. Facebook, Google Plus).
>
classic erroneous supposition.


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

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

-- 

Murphy's list applies;

".--- . ... ..- ..." <tharrison77107@h0tmail.invalid>
00101010 <zerozeroonezeroonezeroonezero@h2g2.cazoola>
3k7e4intna <3k7e4intna@se0tfbhc.k3y0a.p0z>
3x7r4vagan <3x7r4vagan@fr0gsoup.x3l0n.c0m>
3x+r4v4g4n <extr4v4g4n@fr0gs0up.x3l0n.c0m>
Alice <quaxx1108@example.com>
Arne Këndoj <akendoj103@foof.fcl3.org>
Boojum <boojum42@gmai1.c0m>
B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m>
A Canuck <canuck36@tweezit.yahoo.ca>
Canuck <canuck107@canada.xyz>
Cindy <c.thurston@frell.okb.uwa.edu>
ClassCastException <zjkg3d9gj56@gmail.invalid>
Cthun <cthun_117@qmail.net.au>
Chad Carmichael <c_carm10782.x@y.z>
dA.b0mB <dabomb@gmai1.c0m>
dark-zark-fark <dzf190485@rutgers.edu>
Deep Green <d_green11908@gmail.com> (forgery)
Deeyana <d.awlberg@hotmail.invalid>
De Lurker <delancey_s113@harvard.nospam.invalid>
Derek Yancey <dy190295683@nospam.invalid>
Extravagan <extravagan@frogsoup.xelon.com>
Eight of Seventeen <eights17@gmail.com>
Ferdinand the -14th <foo@bar.invalid>
Four of Seventeen <fseventeen@gmail.com>
Fuschia, President-Elect of the Bright Purplish-Green Council
<fp-eotbp-gc@ibm.com>
George Arctos <g.arctos11@hormair.cor>
Greg Kelly <gkelly101_4@gmai1.c0m>
Greg Sandoval <g_sandoval@gcsma.edu.br>
Gheerax IV <gheerax.4@gmail.invalid>
Handkea fumosa <hfumosa@gmail.com>
Hieronymus S. Freely <hsfreely@xavier.uwsc.edu>
Hydrocon <hcon77107@geemail.corn>
Henry Harrison <hharr.1082@quux.bar.foo>
Henderson <h1@g1.f1>
Heike Svensson <hsvensson.1093x1_q@hotmail.nospam.com.please>
Harry Greer <h_greer_1099348@gmail.xxx>
Janie Zanie <jjezebel916@gmai1.invalid>
Jerry Gerrone <scuzwalla@gmail.com>
John Kirkpatrick XVII <jkxvii@ask.me>
Katie Gerrolds <k.gerrolds@nbfinlan.net>
Kevin Hadron <kh_mu_meson@q.us>
kensi <kensi_kensington@zoonoses.de>
KitKat <kitkat_11697@gmail.example.com>
Meerkats <mk_ultra.19018@gmail.com> (forgery)
Mister Scott <m_scott.19477b@noggles.corn>
Movable Hype <mhype101@snortwad.net>
Mrs. Danforth <danforth_a@hotmail.coo>
Mike Faramis <m_faramis808@qmail.nospam.net>
Mamac <mmc.19384_b@gmai1.com>
Nancy 3 <n3@gmai1.c0m>
Nancy 4 <n4@gmai1.c0m> (forgery)
Nebulous <nebulous99@gmail.com>
Nightcrawler <Dirtydeeds@dirtcheap.net>
Nougat Surprise <nsurprise@noway.nohow.invalid>
Orange Green <og_b1823@netmail.zoog.com.au> 
Purpleswandir <ps_1201294@gmail.com>
Retahiv Oopsiscame <roopsisc@gmail.com>
RichB <rich_barnsley@nowhere.com>
scuzwalla@gmail.com
SFTV_troll <SFTV_troll@yah.right>
Some Guy <Some@Guy.com>
Sulfide Eater <zaxx1108@example.com>
<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Spock <spock@starfleet.ufp>
Series Expansion <serexp1@gmail.com>
Seamus MacRae <smacrae319@live.ca.invalid>
sproing <sproing2323@1010.com.quux>
Snicker-snack! <ssnack119@g00glema1l.c0m>
Tim <tharrison77107@h0tmail.invalid>
Thursday's Leftovers <thursday.197@hotmail.com>
thoolen <thoolen@tholenbot.thorium>
thoolen <tholen01@gmail.com>
thoolen <th00len@th0lenbot.thorium>
<th00len@th0lenbot.thorium>
Willy Wonka <w.wonk1028_x@gmail.xyz>
Zapotec <z_gib@wav.com>

Truth in Conclusions.
"At some point, can't we find a bit
of charity for a guy who looks to be in for some real hellish times up
ahead?"
http://groups.google.com/group/alt.fan.kia-mennie/msg/c9946955fb73b48c?dmode=source

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

#10009

Daniel Pitts is a well-known and respected contributor to the Java newsgroups.

-- 
Lew

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web