1. Exceptions
-------Phoenix-Boundary-07081998-
I have recently realized that it may be fairly easy to add
exceptions (multilevel returns) to my 'extended' Euphoria.
procedure foo ()
if ...
throw ("Error in FOO ")
end procedure
procedure foobar ()
foo ()
...
end procedure
procedure zot ()
...
catch s
?(s & " caught in ZOT")
exit()
end procedure
throw would send a single sequence, which would
travel up the stack to the first 'catch'
Any comments?
Karl Bochert
-------Phoenix-Boundary-07081998---
2. Re: Exceptions
On Mon, 18 Mar 2002 13:45:10 -0800, kbochert at ix.netcom.com wrote:
>I have recently realized that it may be fairly easy to add
>exceptions (multilevel returns) to my 'extended' Euphoria.
>
>throw would send a single sequence, which would
>travel up the stack to the first 'catch'
>
>Any comments?
>
Would it be possible for a normally fatal program error to be
converted to a throw, and then be caught?
Would you code the catch statement before or after the call?
I only mention that as I suspect you might have difficulty finding a
catch statement at top level if it is coded after(?). Either way I
would expect:
catch (sequence s)
<statements only executed after thrown exception caught>
end catch
<processing continues here>
Is that about right?
Pete
3. Re: Exceptions
On 18 Mar 2002, at 13:45, kbochert at ix.netcom.com wrote:
>
> I have recently realized that it may be fairly easy to add
> exceptions (multilevel returns) to my 'extended' Euphoria.
>
> procedure foo ()
> if ...
> throw ("Error in FOO ")
> end procedure
>
> procedure foobar ()
> foo ()
> ...
> end procedure
>
> procedure zot ()
> ...
> catch s
> ?(s & " caught in ZOT")
> exit()
> end procedure
>
> throw would send a single sequence, which would
> travel up the stack to the first 'catch'
>
> Any comments?
1a) Great!
1b) Wonderful!
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()?
Kat
4. 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---
5. Exceptions
What I consider missing in Eu is some mechanism to resume after error is agreed
upon and implemented.
I think Eifel's system is a little too clean and rigid, while Basic's is
flexible but not clean.
In Eiffel:
my_routine(args)[:return type] is
-- skipping pre/postconditions
do
-- code goes here, skipped local var section
<optional>
rescue
-- rescue code
</optional>
end
The rescue code can only do three things:
* restart the routines, using the reserved word retry;
* return normally after ensuring a stable, consistent state for the system
* fail, by not handling the exception, or throwing a different one.
In Basic, there are diretives like
on error go to <line>
on error resume
on error next
which are pretty self explanatory.
I'd suggest mixing the two, by using Eiffel's scheme and adding a resume_next
and retry_statement keywords. retry would be renamed retry_routine. It would
crash in top level code.
CChris
