From: Pitch on 27 May 2010 05:22 In article <alpine.DEB.1.10.1005261957240.16996(a)urchin.earth.li>, twic(a)urchin.earth.li says... > > On Wed, 26 May 2010, Gunter Herrmann wrote: > > > Tom Anderson wrote: > >> On Tue, 25 May 2010, Arne Vajh?j wrote: > > > >>> But I would note that in many cases the optimal solution is to > >>> wait declaring the variable until you have a value to give it. > >> > >> Absolutely. Goes without saying! > > > > There are exceptions to this rule (pun intended) > > > > Foo foo = null; > > > > try { > > foo = new Foo(); > > foo.doProcessing(); > > } > > catch (FooException ex) { > > doSomething(ex); > > } > > finally { > > foo.cleanup(); > > } > > > > In this case you have to initialize the variable foo. > > No, because you should just write it like this: > > Foo foo = new Foo(); > try { > foo.doProcessing(); > } > catch (FooException ex) { > doSomething(ex); > } > finally { > foo.cleanup(); > } > > If new Foo() can also throw an exception, then wrap that whole lot in a > try-catch or whatever. > > tom If new Foo() throws an exception it's not a problem. If you see this block as an atomic function "doSomethingFoo()" the caller has to handle exceptions but the callee has to clean up resources it has allocated. On the other hand if you DON'T see this as an atomic function - I'd say it's bad design. :) -- stirr your cofee properly
From: Pitch on 27 May 2010 05:25 In article <4bfdbc76$0$277$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk says... > > If new Foo() can also throw an exception, then wrap that whole lot in a > > try-catch or whatever. > > But in that case the improvement is so so. Improvement is in that it forces you to decouple your code into smaller methods, which is a huge thing to me. Anyway, it's an old subject, we've all already disagreed on that a year ago. :) -- stirr your cofee properly
From: Lew on 27 May 2010 07:51 RedGrittyBrick wrote: > I'm always a little uncomfortable when the exception handling overwhelms > and obscures the business logic: > > new Foo().process().cleanup(); // <stimpy>Sigh!</stimpy> Is your sigh because the 'cleanup()' call might never happen this way? This simplified code represents the problem the other idioms solve. > The point of the exception handling mechanism is to separate error > handling code from business logic code. Sometimes it is hard to achieve > this. The point of the 'finally' block is to ensure code runs even when earlier code completes abruptly. -- Lew
From: Mike Amling on 27 May 2010 09:40 Patricia Shanahan wrote: > I follow the extreme opposite view. I initialize a local variable at the > point of declaration if doing so makes logical sense or I know that I > know something the compiler does not know. Generally, that involves the > compiler assuming a fall-through from a call to System.exit. I started following all calls to System.exit and to my own non-returning functions with throw DONT; to notify the compiler. That allows it to do assignment checks and to find dead code. (DONT is a statically declared RuntimeException instance that is never actually thrown.) --Mike Amling
From: Roedy Green on 27 May 2010 22:43 On Tue, 25 May 2010 20:37:33 +0000 (UTC), Rhino <no.offline.contact.please(a)example.com> wrote, quoted or indirectly quoted someone who said : > >Basically, I initialize pretty much every variable as I declare it, just to >be sure it has some kind of value right away. That initial value is >typically a zero for a number or a null for an object. Some recent >criticism questioned this practice so I thought I'd review some of the >material that helped get me in that habit in the first place. If that interim value is meaningless, you prevent the compiler from detecting missing "real" initialisations. -- Roedy Green Canadian Mind Products http://mindprod.com Beauty is our business. ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72) Referring to computer science.
First
|
Prev
|
Pages: 1 2 3 4 5 6 7 Prev: StrutsTestCase and Netbeans Next: Centralizing instantiation? |