OpenEuphoria

RE: [Windows] Associate file extensions with a program

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

Chris Bensler wrote:
> 
> What you want is error trapping and exception handling.
> 
> I've written a library to deal with this..
> It's not perfect, because we can't bail out of the call stack, but
> otherwise, it's a good solution for error trapping.
> Note also, that error trapping puts the sanity tests into the routines
> that are actually making the errors. That is how it should be.
> Error trapping also keeps the routine's result unambiguous.
> 
> here is a psuedo-example...
> ------------------------------------
> allow_error_trapping(OFF)
> allow_pending_errors(OFF)
> 
> constant ERR_FOPEN = define_error(NULL)
> function fopen(sequence name, sequence flags)
>   integer fn
>    if fn = -1 then
>      throw_error(ERR_FOPEN,"Failed to open "&name&" with the flags:
> \'"*flags&"\'\n")
>    end if
>    return fn
> end function
> 
> -- now I can do stuff like this..
> integer fn1,fn2,fn3,fn4,fn5
> fn1 = fopen("foo1.txt","rb")
> fn2 = fopen("foo2.txt","rb")
> fn3 = fopen("foo3.txt","rb")
> fn4 = fopen("foo4.txt","rb")
> fn5 = fopen("foo5.txt","rb")
> trap_error(ERR_FOPEN)
> ----------------------------------------
> In that specific example, trap_error() is not even needed at all.
> 
> If allow_error_trapping() is OFF, allow_pending_errors() has no affect.
> 
> With allow_error_trapping(OFF), each error is thrown and called
> immmediately. throw_error() acts like a regular error msg routine.
> For example, if foo1.txt fails.. the error occurs immediately within
> fopen()
> 
> With allow_error_trapping(ON), and allow_pending_errors(OFF), each error
> is thrown, but is not called unless an error is already pending.
> For example, if foo1.txt fails, and foo3.txt fails, the error will be
> thrown for foo1.txt when the error for foo3.txt is discovered.
> 
> With allow_error_trapping(ON) and allow_pending_errors(ON), each error
> is thrown, and only called via trap_error()
> For example, if foo1.txt fails, and foo3.txt fails.
> Eu will still process each fopen statement. When it reaches, and calls
> trap_error(ERR_FOPEN), it checks for any pending errors, matching that
> ERR_FOPEN, and calls the first occurance. (An error would be
> instantiated for foo1.txt)

This seems very similar with the error handling I use in EuSQL (except
that it has to bail out of the call stack).  There's even an 'automatic' 
way, using a user defined type (EUSQLRESULT), to get errors reported to 
the user, and this can cause the app to shut down or not (user-defined).  
I tend to use it for debugging and testing mostly, since it shuts down 
and allows me to see where things went wrong.

I assume there must be a way to get at the error information in your
library.  How do you recover from an error (i.e., what would you do if 
foo1.txt didn't open, but you needed it to continue)?

Matt Lewis