On Dec 22, 2007 6:38 AM, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
> I don't think it's directly relevant, unless John C is using exceptions
> for flow control.
The facility is used under the covers for flow control, but is also
exposed directly to the user. I'm planning, based on what you two
have written, to implement four cases, in increasing order of
generality. I'm writing them down here in case they help anyone else.
Note that the style is "catch (tag) { body }" and "throw(tag,
value)", where in both cases "tag" is evaluated at run time, so the
tag being thrown is independent of the value being returned.
1) If the thrown value is manifest, and
1a) the catch is the top-level expression in the same procedure, then
implement the throw as "return value;".
1b) the throw is in the same procedure as the catch (but not in any
nested procedure), then implement it as "temp = null; foo: do { ...;
temp = value; break foo; ...} until true;".
1c) the catch and the throw are in different procedures, then use the
unique instance of a unique subclass of CatchPoint.
2) If the thrown value is not manifest, use an instance of CatchPoint
directly, storing the run-time object in its sole field. CatchPoint
suppresses tracebacks.
Of course when I say "manifest", I mean "manifest at both the catcher
and the thrower".
I should also add that a native Java exception can be caught; things
are arranged so that the catcher sees the thrown tag as the
exception's class (that being a unique object) and the thrown value as
the exception object itself.
> What I would be interested in hearing is if N catches are more expensive
> than one catch, or if catching at all already has done the damage and
> adding additional catches doesn't make much difference.
I'd like to know that too.
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
