> imanhp@gmail.com wrote in news:1139180450.334075.96290
> @g44g2000cwa.googlegroups.com:
[quoted text clipped - 15 lines]
> as this input problem. The Scanner class provides methods to avoid
> exactly this.
Aren't try/catch blocks also fairly expensive? Putting one inside a
while loop seems like a bad habit. Granted, in this particular case,
the intention is for the loop to iterate very few times, and the loop
is also dependent on user input, which will in any case be much slower
than whatever code is being processed.
Still, it seems like something to avoid, much like always-true loops.

Signature
monique
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
zero - 06 Feb 2006 20:56 GMT
> Aren't try/catch blocks also fairly expensive?
Yep, that's one of the main reasons to use alternatives when they are
available. The program flow with try/catch blocks is very complex - even
more so if there's a finally block - and require a lot of internal
computations.
Which does not mean you have to stay away from exceptions altogether.
Structured exception handling is a very good thing, as long as it is used
for what it was envisioned to do: handle exceptional situations, not
situations that happen in normal program flow. Incorrect user input falls
under the normal category.
Thomas Hawtin - 06 Feb 2006 21:21 GMT
>> A loop with an always-true condition is usually a *very* bad idea. Only
>> experienced programmers should ever do this, and only with a very good
>> reason.
Unless you are of the Single Entry Single Exit (SESE) persuasion, using
a break or return to exit a loop seems reasonable. Using an auxiliary
boolean variable complicates matters. Duplicating conditions is
repeating yourself (keep it DRY).
> Aren't try/catch blocks also fairly expensive? Putting one inside a
> while loop seems like a bad habit. Granted, in this particular case,
> the intention is for the loop to iterate very few times, and the loop
> is also dependent on user input, which will in any case be much slower
> than whatever code is being processed.
Not really.
Creating exceptions is excessively expensive. Throwing exceptions is
moderately expensive.
Remember that a synchronised block is effectively a try/finally. We have
known synchronisation (in normal circumstances) isn't expensive for
years. Perhaps you the worst thing you can say about try blocks in
relation to performance is that they may prevent inlining on some JVMs.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Monique Y. Mudama - 07 Feb 2006 20:19 GMT
> Unless you are of the Single Entry Single Exit (SESE) persuasion,
> using a break or return to exit a loop seems reasonable. Using an
> auxiliary boolean variable complicates matters. Duplicating
> conditions is repeating yourself (keep it DRY).
What does DRY mean?

Signature
monique
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Thomas Hawtin - 07 Feb 2006 22:20 GMT
>> Unless you are of the Single Entry Single Exit (SESE) persuasion,
>> using a break or return to exit a loop seems reasonable. Using an
>> auxiliary boolean variable complicates matters. Duplicating
>> conditions is repeating yourself (keep it DRY).
>
> What does DRY mean?
Don't Repeat Yourself.
"DRY says that every piece of system knowledge should have one
authoritative, unambiguous representation. Every piece of knowledge in
the development of something should have a single representation. A
system's knowledge is far broader than just its code. It refers to
database schemas, test plans, the build system, even documentation."
-- http://www.artima.com/intv/dryP.html
In this narrow case, the little piece of system knowledge was when to
exit the loop.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Monique Y. Mudama - 07 Feb 2006 23:32 GMT
>> What does DRY mean?
>
[quoted text clipped - 9 lines]
> In this narrow case, the little piece of system knowledge was when
> to exit the loop.
Ah. Thank you. I hadn't heard of the acronym, but I agree with the
sentiment!

Signature
monique
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Chris Uppal - 07 Feb 2006 08:28 GMT
> Aren't try/catch blocks also fairly expensive?
No. It's implementation-dependent but there is no reason (given any reasonable
implementation technology) why it should have /any/ direct time cost at all.
The indirect costs may be non-zero. For instance a try/catch might interfere
with optimisation in the JIT (if any). The records required to implement
zero-cost try/catch take up some space, and hence some (tiny) time too. But I
doubt if such effects are worth worrying about in most cases.
Actually throwing/catching an exception is, naturally, a different kettle of
fish entirely.
-- chris
zero sez:
> imanhp@gmail.com wrote in news:1139180450.334075.96290
> @g44g2000cwa.googlegroups.com:
[quoted text clipped - 11 lines]
> experienced programmers should ever do this, and only with a very good
> reason.
And reading user input tends to be one of them. Typical scenario
is when you want to give them a limited number of tries (loop
with a counter: for), validate the input (post-condition loop:
do .. while), *and* let them hit Esc and abort the whole thing
(break/exit in the middle). It doesn't really fit into any of
the proper structured programming constructs, so you might as
well go for while(1).
Dima

Signature
We're part of that admittedly-too-small group that is trying to save the
human race from itself. With any luck, we'll fail abjectly and the
cockroaches will win out.
-- Mike Andrews