Re: toward null-safe cookie cutter Comparators
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.