Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: About java program. Date: Thu, 20 Jun 2013 19:18:34 +0200 Lines: 74 Message-ID: References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> <19wnriq53qxel.u9rt8wy6z52g.dlg@40tude.net> <1lvu4yv8sxe73$.n4o05ixuag9y.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net RoNRRWns7ZrBIVJbnMA9NAbWoRTFJPknJZaV+DXqaFoTUUM88= Cancel-Lock: sha1:Kz+vP3AXQ/0edD4c+cD8PJdOZrc= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 In-Reply-To: X-Antivirus: avast! (VPS 130620-1, 20.06.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:24487 On 20.06.2013 10:23, Sven K=F6hler wrote: > Am 19.06.2013 22:20, schrieb Robert Klemme: >> boolean result =3D false; >> try { >> result =3D whatEver() || somethingElse(); >> } >> catch (whatever...) { >> no return or change of result >> } > > I would like to add, that I dislike the initialization of result in thi= s > example. If result (for whatever reason) must be declared outside the > try-catch block, then please don't initialize it unless you plan on > doing something nasty. Absolutely. The reason is that by initializing the variable you forgo=20 the Java compiler's data flow analysis. Without initialization you will = immediately know if there is a code path which uses the variable without = prior initialization. > A nasty example would be that the try block sets > result to true midway and an exception in the second half doesn't chang= e > the value of result to false for some weired reason. Right. > The IMHO cleaner way is the following: > > boolean result; I'd even recommend making that variable final if possible. > try { > result =3D whatEver() || somethingElse(); > } > catch (whatever...) { > result =3D false; > } > // use result for whatever Generally I prefer not to have code after the catch block (unless it's a = finally block :-)) because that means that error handling is not=20 centralized but rather interspersed with other logic. I have seen=20 methods with multiple try catch blocks in them on the same level which=20 made them really unreadable. If that is necessary then I'd either=20 combine catch blocks and if that cannot be done I'd rather refactor=20 reasonable sections into separate methods. > And may all (ex-)C programmers in this group refrain from telling me > that not initializing variables is dangerous. This is Java, where the > compiler enforces initialization of variables on all code paths before > the first read-access to the variable. Exactly. And another difference to C is that you can declare variables=20 anywhere - not just at the top of the method body. I have seen too many = Java methods which did that and used the variable 30 lines below. That=20 really makes reading and understanding code hard. Cheers robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/