On Mon, 12 Dec 2005 21:02:39 -0000, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly
quoted someone who said :

I invented such tools in my BBL and Abundance language.  I used them
only for constructing early return verbs, not for jumping up many
levels.

e.g.  for example  in Abundance you can say    

aBoolean ?EXIT>>>

instead of  

aBoolean IF EXIT>>> THEN

or

aBoolean ?YES>>>

instead of

aBoolean IF YES EXIT>>> THEN

(returns value yes if true, otherwise carries on)

Chris Uppal wrote On 12/12/05 16:02,:

   The syntax doesn't bother me much, although there's a
certain amount of clumsiness about try/catch/finally.  The
fact that each of the three blocks has its own scope means
that there's no single scope for the entire construct; this
makes me declare variables at a scope wider than they really
ought to have, or introduce an extra level of { } simply to
create a containing scope.  And it's irritating to catch an
IOException, say, and then put yet another try/catch inside
the finally that closes the BufferedReader or whatever.  But
these are just cosmetic issues, nothing I can't live with.

   Nor is the shape of the control flow a problem.  The route
taken by a Java exception has the right balance of unpredictable
(the thrower doesn't know the catcher) and predictable (the
catcher will necessarily be an active call frame).  A goto style
(e.g., PL/I or Pascal) loses the flexibility of "anonymous" (or
else requires label variables, which are hard to validate), while
the trust-the-programmer style of C's longjmp() all too often
engenders really horrible bugs.  Java exceptions unwind in a
calm and orderly fashion, which I find soothing.

   My objections to control-flow-by-exception are twofold.
First, there's efficiency.  Yes, I know it's unfashionable
to talk about efficiency, but those of us who programmed in
Olden Times formed the hard-to-shake habit of keeping it in
mind.  I'm still an efficiency addict (on, er, method-done
treatment ;-), and cannot help but think of all the cycles
that must be spent on a throw/catch.  Even if you pre-construct
the thrown exception, the JVM still needs to conduct a possibly
lengthy search up the stack to find candidate catch blocks; a
chain of returns -- even if a method result must be if'ed at
each level -- will almost certainly be faster.

   My other objection is a "right job, wrong tool" feeling.
Sure, it's possible to use exceptions for control flow, but
Java's control flow constructs are there because they're more
convenient, more readable, and better suited to the task.  One
can replace a "switch" with a try/catch/catch/catch/catch...
block, but that doesn't mean one ought to.  Exceptions should
be, well, exceptional -- they're not called Normals, after all!
I like to think of a method as having a contract that in normal
circumstances is "contained" in its arguments, its returned
value, and the states of the objects it touches.  When I call
the method, I want it to return with its contract fulfilled.
Exceptions are for when there's something that prevents the
method from fulfilling its contract: invalid arguments or state,
I/O errors, whatever.

   So: My objections amount to an old-fashioned concern for
efficiency combined with a Puritanical fastidiousness.  Neither
is binding on anyone else; follow your weird.

   Personally, I don't like the API you've exposed. For one thing, it's
impossible to get a negative parse value, despite the existence of a
"NegativeIntegerParseResult" class. For another thing, having an instance of
a class doesn't imply that you actually have a legal value, because of the
"hasValue()" boolean. That means that every method that takes in an instance
of IntegerParseResult has to check to make sure that the value is actually
present:

<code>
public void methodA(IntegerParseResult ipr) {
 if (!ipr.hasValue()) {
   throw new IllegalArgumentException();
 }
 if (conditionA) {
   //Do something
 } else {
   methodB(ipr);
 }
}

public void methodB(IntegerParseResult ipr) {
 if (!ipr.hasValue()) {
   throw new IllegalArgumentException();
 }
 if (conditionB) {
   //Do something
 } else {
   methodC(ipr);
 }
}

public void methodC(IntegerParseResult ipr) {
 if (!ipr.hasValue()) {
   throw new IllegalArgumentException();
 }
 if (conditionC) {
   //Do something
 } else {
   methodA(ipr);
   methodB(ipr);
 }
}

public mainMethod() {
 methodA(LessException.parseInt("foo"));
 methodB(LessException.parseInt("25"));
 methodC(LessException.parseInt("-42"));
}
</code>

   I'd rather just deal with the exception right away in main, then having
to worry about it EVERYWHERE in my code.

   - Oliver

Having spent the better part of two days recently rewriting a deeply recursive
algorithm into a pure (no local variables) iterative formulation, and /NEVER/
wanting to do so again, I cannot but feel that this poor advice...

   -- chris

Java's bytecode-level representation of exception handlers is set up very
obviously for zero-cost try blocks.  That's to say that /entering/ a try block
has zero overhead.  The downside, of course, is that if an exception is
actually thrown, then finding and invoking the handler is not as cheap -- isn't
even constant-time.

Implementation are free to implement throw/catch how they like, but since the
hardest part of doing zero-cost try blocks is creating the stack maps, and in
Java bytecode the compiler is required to do that work for you, I think it
would be odd for a "normal" JVM implementations to use any other technique.

   -- chris