Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.46.80.MISMATCH!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: Sun, 20 Nov 2011 08:23:36 -0800 (PST) Organization: http://groups.google.com Lines: 63 Message-ID: <22790268.15.1321806216236.JavaMail.geo-discussion-forums@prgt40> References: Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 173.164.137.214 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1321806648 4362 127.0.0.1 (20 Nov 2011 16:30:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 20 Nov 2011 16:30:48 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.164.137.214; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10098 On Sunday, November 20, 2011 4:29:30 AM UTC-8, Wanja Gayk wrote: > In article ,=20 > newsgrou...@virtualinfinity.net says... >=20 > > Perhaps in this case, but the point still stands that null propagation= =20 > > can make bug diagnosis much more difficult. >=20 > Even though I do second you on that, reality says: You rarely have a=20 > chance to avoid null propagation and null checks, because you can't=20 > write everything for yourself,=20 So what you're saying is that you can only maintain code to which you have = access to the source code. Frikkin' brilliant. > not every project is a greenfield project=20 > and sometimes leaving a null somewhere is the quick option that your=20 > project lead is willing to pay (think of partially populating models in= =20 > 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 skip null checks. If they= do, I ignore them. If they insist, I tell them to stuff it. What a ridic= ulous concept. How unprofessional can one be? A 'NullPointerException', like other runtime exception, evidences a program= ming error. You just spoke up in favor of deliberately programming bugs in= to the code. Stupid, stupid idea. Please do not work on any project I car= e about. The overhead of checking data validity (e.g., non-null inputs 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. No= one who knows software development should be so stupid as to suggest delib= erately increasing the cost and reducing the correctness of a program like = that. Good managers work to reduce risk and cost. The point is that you catch such exceptions as early as possible. DUHHH, o= f course you can't catch it in the middle of some third-party API call, but= you can catch it the moment that call returns to your code, and that's wha= t was recommended to limit exception propagation. Pinning it to third-part= y code suffices, so your point was specious. The cost of writing the checks up front is orders of magnitude, yes, orders= of magnitude (base 10), cheaper than skipping it and coming back later, in= most cases infinitely cheaper since you'll never get the chance to go back= to correct your stupidly deliberate mistakes. So let's push back on idiotic, stupid suggestions like, "Let's make the pro= gram correct later - just get it done incorrectly for now." What a maroon! --=20 Lew