Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin1!goblin.stu.neva.ru!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: toward null-safe cookie cutter Comparators Date: Mon, 21 Nov 2011 14:20:10 -0800 (PST) Organization: http://groups.google.com Lines: 96 Message-ID: <2113828.215.1321914010550.JavaMail.geo-discussion-forums@prlm15> References: <22790268.15.1321806216236.JavaMail.geo-discussion-forums@prgt40> <9e8b681f-055f-4588-9ef6-3702322b4d3e@c4g2000vbh.googlegroups.com> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 2620:0:1000:2404:224:d7ff:fe69:5838 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1321914011 13545 127.0.0.1 (21 Nov 2011 22:20:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 21 Nov 2011 22:20:11 +0000 (UTC) In-Reply-To: <9e8b681f-055f-4588-9ef6-3702322b4d3e@c4g2000vbh.googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2620:0:1000:2404:224:d7ff:fe69:5838; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10168 Brixomatic wrote: > Lew wrote: >> First of all, my project lead doesn't tell me to skipnullchecks. =A0If t= hey do, I ignore them. > >=A0If they insist, I tell them to stuff it. =A0What a ridiculous concept= . >=20 > 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"? =20 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 arg= ument 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 cust= omer see the exception, because you NEVER let the customer see the exceptio= n. 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 mandat= e for ignoring them, which is the shortest path to ensuring that the custom= er sees them. What do I misunderstand here? > > How unprofessional can one be? >=20 > > A 'NullPointerException', like other runtime exception, evidences a pro= gramming error. > > You just spoke up in favor of deliberately programming bugs into the co= de. =A0Stupid, stupid > > idea. =A0Please do not work on any project I care about. >=20 > 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 metho= d) is far, far lower when first coding then it is later when you try to fig= ure out all the places where you stupidly decided to leave out the checks. >=20 > I don't disagree at all. >=20 > > =A0No one who knows software development should be so stupid as to sugg= est deliberately increasing the cost and reducing the correctness of a prog= ram like that. >=20 > No one "should" but reality is: Some are. >=20 > > Good managers work to reduce risk and cost. >=20 > 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 ra= tional. > > The point is that you catch such exceptions as early as possible. >=20 > 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 w= ith 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 engineeri= ng content, so I cannot respond except to applaud your imagery. --=20 Lew