OpenEuphoria

Re: exception handler

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 24, 2004
• 609 views

On Tue, 24 Aug 2004 13:55:16 -0700, irv mullins
<guest at RapidEuphoria.com> wrote:

>Pete Lomax wrote:
>
>> It should be the *end* of the try block, or some explicit code as in a

>I see it's structured.

Erm, be careful what you mean here; structured exception handling is
designed to work well with structured (IE *subroutined*) code, not
necessarily exception handling which is itself structured. Think of
something nasty happening miles away, say mid-way through pushing one
of several parameters.

Of course I plan/hope for both.

> I can also see there's no way to go back and 
>try again if it fails. Suppose the open(... fails. 
>That would be fail=1, right? So what does the "if fail=1 then" do?
>Go back and try again? If so, How?

fail=9
while fail do
	try...
end while

OK, you may have a point, it would be annoying to have to reset a
control var in *every* case. That said, I *will* sacrifice a few extra
lines of code to make the control flow clearer, though.

What I would hate to see is a design whereby we have:

	try
		<code to handle the failure cases>
		<code which might fail>
	end try

because that is harder to follow.

OTOH, thinking about it out loud, I guess I don't really have a
problem with eg:

	catch
		overflow:
			...
		divide_by_zero:
			...
	in
		<code>
	end catch

or, indeed:

	catch while
...

(assuming:
	if "while" then
		"exit" jumps to the end catch
		no exit resumes at "in" (bit like "else")
		"end catch" loops
	else (just "catch", no "while")
		after catch, control resumes at "end catch"
		"exit" is illegal
		"end catch" does not loop
	end if
	in both cases, of course, there is an implicit jump to the "in" 
	 part at the start of the block.
)

Still upside-down, but possibly bearable,
Actually, I quite like that...

Pete