OpenEuphoria

Re: exception handler

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 24, 2004
• 461 views

irv mullins wrote:
> 
> Pete Lomax wrote:
> 
> > It should be the *end* of the try block, or some explicit code as in a
> > try/catch/end try statement. This makes it much clearer where to put
> > code to check what failed, eg:
> > 
> > 	try
> > 		fail=1
> > 		open(...
> > 		fail=2
> > 		getc(...
> > 		fail=3
> > 		close(...
> > 	catch
> > 		if fail=1 then
> > 		elsif fail=2 then
> > 	end try
> > 
> > Of course if you use three try blocks, you don't need a fail variable.
> > If you want it to loop, add a loop around the try block(s).
> > 
> > Pete
> > PS The above is structured exception handling, and as I said in my
> > other post, Rob should get a simpler final exception handler working
> > first.
> 
> I see it's structured. 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?

I think that there's no way to go back here because it's a simple 
example, similar your example using types.  Pete's idea is just an
extension of this, but it provides for an automatic way to handle the
exception, rather than simply continuing execution, and forcing you
to set a flag or some other manual thing.

Your example tells the user that the file is bad, but you don't provide
for dealing with a bad file handle.  It would have to be manually checked,
as opposed to returning from the procedure after notification, or whatever
seems the right way for the app to handle the exception.

My take on structured exception handling is that it's really just a formal
and 'official' way to validate things.  I guess the benefit is that the
validation can be more easily modularized and automated (i.e., through 
type checking).

I'm not very savvy with regards to this topic, but what would/should 
happen in this case:  

type file( object o )
    if not integer(o) or o = -1 then
        return 0
    end if
    return 1
end type

file fn
procedure foo()
    -- for simplicity, suppose we try to open a 
    -- bad file, causing fn = -1
    fn = open("bad file name", "r" )
end procedure

procedure bar()
    try
        foo()
    catch
        return
    end try
    
    ? get(fn)
    close(fn)

end procedure
bar()

Would the try block apply to exceptions in foo()?  What if foo() had 
its own try block, and caught the exception, but can't fix it--in other
words, we have a bad result, and we know that the result of foo() is 
depended upon later?  Do we need to explicitly throw() an exception up 
the chain in order for bar() to know that there was an exception? What 
happens to fn?  Does it stay unassigned--or if previously assigned, does 
it keep its old value?

I know a lot about this topic has been discussed before, but I had a tough
time staying awake through the discussions. :(

Matt Lewis