Java: Helping the world build bigger idiots

[Jerrold Leichter]

| It used to be that checking bounds on certain collections was less
| efficient than waiting for the out of bounds exception. I think Joshua
| Bloch discusses this in his book.
| 
| I've also seen this in generated code where you aren't sure of the
| nature of the object you're indexing and thus don't know the
| appropriate length variable (.length vs .length()).
| 
| That said it's still awful.
I must admit I don't see the objection.  Exceptions are a natural way to
report "end of container" - at least in a language where they are native and
intended to be efficient.  C++ is *not* such a language:  Exceptions were
grafted on - a graft that still shows in many places - and it is widely known
that implementations are supposed to optimize the "no exceptions" case, even
at the expense of the "exceptions" case.  In fact, the norm is *no* cost when
there are no exceptions, paid for by searches through encoded tables in
each enclosing try block until you find one that matches.

Just because two constructs in two different languages are lexically and even
semantically similar doesn't mean they equivalent in intended/supported usage.
Language styles differ, sometimes dramatically.

(BTW, perhaps I don't find this usage so disturbing because I'm an old
SNOBOL4 hacker.  SNOBOL4 way pre-dates exceptions - it was mature by the
early '70's - but it did have a vaguely similar notion that an expression
could either succeed - returning a value - or fail.  Failure propagated out
through expresssions - suppressing further evaluation - to the nearest
containing statement, where it drove control flow.  Out-of-bounds access to
an array caused expression failure.  The usual way to walk a look was to
increment an index until the indexing operation failed - just as here.
(BTW, SNOBOL4 also explicitly specified the order of evaluation of expressions
and the initial value of variables.  Common SNOBOL4 programming idioms relied
on these guarantees.  These idioms would be a disaster in most other languages
- but so what.  Many of these idiomatic styles did make it into later
languages, Icon in particular.)

One thing to consider is that an idiom like this solves an annoying problem.  
Consider a linear search through an array:

	for (i = 0; i < lim; i++)
	{	if (a[i] == target)
		{	<do something>
			break;
		}
	}
	/*
	 * Did we get here because we matched or because we
	 * failed to match?
	 */

How many times have you written code at <do something> - like setting a
"found" Boolean - just to distinguish the two exit states?Contrast with:

	try
	{	for (i = 0; i++; )
			if (a[i] == target)
				break;
	}
	catch (IndexOutOfBoundsException ex)
	{	/*
		 * We *didn't* find the target
		 */
	}
	/*
	 * If the catch falls through, we still need to
	 * disambiguate, but often the catch either adds
	 * the missing element, or returns a failure.
	 */

Personally, I sometimes use:

	for (i = 0; i < lim; i++)
	{	if (a[i] == target)
			goto found;
	}
	/*
	 * We *didn't* find it
	 */
	...
found:
	/*
	 * We *did* find it
	 */

This draws shock and horror from some code readers, but I don't care.  :-)
Note how much it looks like the exception-based code.

							-- Jerry


| On 9/19/05, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
| > Found on the Daily WTF, http://www.thedailywtf.com/forums/43223/ShowPost.aspx:
| >
| >  try {
| >    int idx = 0;
| >
| >    while (true) {
| >      displayProductInfo(prodnums[idx]);
| >      idx++;
| >      }
| >    }
| >  catch (IndexOutOfBoundException ex) {
| >    // nil
| >    }
| >
| > The editor also comments that when he got the first few of these submitted
| > he rejected them as being faked, but ended up with so many that he
| > realised this usage must be relatively common.
| >
| > Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com