Re: java question

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Viktor" == Viktor Pavlenko <vp@example.com> writes:

    Viktor> "Stephen J. Turnbull" <turnbull@example.com> writes:

    >> (defun integer-mung ()

    >> (catch 'value (integer-mung))

    Viktor> Invalid input is not handled here, in java
    Viktor> NumberFormatException is defined so that you can and must
    Viktor> handle it (a good thing after all)

Oh.  Not a problem.  Just add (not (integerp i)) to the or (oops,
you're right, or, not and).  I didn't do it because I didn't realize
it was a standard exception.  So that's why he used NFE instead of
something more accurate like RangeException?

I guess you'd also want to add an additional level of complexity in
that you'd want to catch errors that occur if the user typed an
invalid Lisp expression.

In Java, though, the user range check and the runtime format check
would be unified.  The only problem is that since the invalid input is
handled in the runtime, you don't get to choose the sense of the
exception.  So I guess the Java would have to be something like

int integer_mung (void) {
  try {
    int i = Integer.parseInt(readUserInput());  // read it
    if (i <= 10 && i >= 0)                      // test it
      return i;                                 // give it back
    throw new NumberFormatException;            // grmbl
  } catch (NumberFormatException) {             // Customer Service Desk
    return integer_mung();                      // three for a quarter?
  }
}

At this point somebody who knows Java ought to be able to massage it
into something elegant and useful.  ;-)

The only problem is that Lisp implementations typically expect to have
many MB of stack space.  I dunno about Java.  In this application, you
don't care, probably; a user is not going to sit there making the
thousands of mistakes it would take to overflow even a 64kB stack.
But this style of programming can use a lot of stack iwth lots of
recursion (eg, Emacs Lisp normally detects infinite recursion after a
thousand recursive invocations, and there are applications which reset
that limit higher ;-).

    Viktor> Just tried this in emacs (having replaced and with or). Is
    Viktor> this a common way of doing things in lisp? I mean throwing
    Viktor> exceptions just to jump somewhere?

Well, these aren't really exceptions.  That's why the idiom is throw
and catch, not try ... except (as in python).  This is cheap in Lisp
(it's just a special case of deferencing a dynamically bound value,
after all).

Most Lisps also have errors which are implemented similarly as
nonlocal control transfers, but have additional semantics (eg, they
can be continuable if caught in the debugger) and are globally caught
by the runtime environment (if you throw something there is no catch
for, it turns into an error, which is caught by the runtime
environment).  They can be caught by user code with `condition-case'
(in Emacs Lisp).

If you're _really_ interested, look up call-with-current-continuation
in the Scheme literature.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."