From: Pitch on
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
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
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
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
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.