Re: Exceptions
-------Phoenix-Boundary-07081998-
Hi Kat, you wrote on 3/18/02 7:56:22 PM:
>1a) Great!
>1b) Wonderful!
>
And fun too!
>2a) can the catch() in zot() peek at more than one throw()?
>2b) will multiple throws be nested s?, in keeping with Euphorian
sequences?
>2c) will those nested throws be named as to who threw them? Like
>{{"foo","Error in FOO "}{"foobar","dbz error"}{"zot","it broke"}}
>
>3a) can zot() catch what it is looking for and ignore the rest of the
>throw()s?
>3b) will the ignored throw()s keep passing up to whoever called zot()?
>
Some (current) details.
1) Throw saves its argument and then searches for a catch phrase
to pass control to. It first checks itself (a routine can
catch its own throw). It next checks its caller, then its
callers' caller, etc. (It can skip multiple intermediate
routines). If no caller is found with a catch, it checks
for a procedure named 'catch' and goes to that. If there is
no such procedure, it exits with a 'Uncaught Exception'
error.
2) When a catch phrase receives control, a top-level variable
holds the sequence which was the throw's argument. There
can be some other variables which hold auxilliary information
such as the calling procedure's name.
3) Exceptions are not nested. A catch phrase may choose to throw
a new exception, which replaces the current one, or may
re-throw the current one by calling throw() with no parameter,
or may ignore the exception and just return.
4) There ought to be a way of classifying exceptions. Currently
a programmer can do this himself in the sequence that is
thrown, i.e. 'throw ({EX_FILE, "File not Found"}), but
a more formal scheme may be possible.
5) I will probably recast most internal errors as exceptions
to enable a user written catch to intercept them.
This seems to be a significant addition, and surprisingly
easy to implement. (Of course I haven't done it yet!)
Karl Bochert
-------Phoenix-Boundary-07081998---
|
Not Categorized, Please Help
|
|
