Re: string_exec()

new topic     » goto parent     » topic index » view thread      » older message » newer message
katsmeow said...
petelomax said...

Please try to provide specific examples to back up any comments or claims.

I have no clue to the structure of compiled OE,

No problem. It should suffice to talk about the structure of eu.ex and execute.e

katsmeow said...

but what if the line containing the string_eval() caused a Non-Fatal interrupt, the line was evaluated to be a valid string_eval(), it (or the file it mentions) is compiled and then inlined (rather more of a local gosub in machine code) in place of the line which caused the interrupt, and then program flow resumes normally from the point of interrupt?

So basically, if a NFI occurs, but it happens to a statement that's usable inside a string_eval() call, then replace the line with a string_eval() call to the original statement.

So, assuming that division by zero is an NFI, when we execute

? 1/0 

and hit the NFI, we rollback and replace it with

string_eval("? 1/0") 

Presumably, calls to string_eval() that throw an error will not crash the main program, but only stop execution of the eval'd code and set some kind of error flag that can be checked later.

In short, you are suggesting that we use string_eval() to implement "ON ERROR GOTO NEXT" error handling behavior, with perhaps some minor differences.

The basic concept is sound.

katsmeow said...



Again, from a clueless perspective, this smells like it will cause the least headaches in var/procedure scopes, as well as goto and name scopes (include balh.e as balh). No new environments would need to be built, no massive copying of var tables, permission slips, colors, or battery voltages. If the string crashes because it assumes something blah blah blah, then it's a normal blah blah blah program crash.

A working code example:

     .timer 1 %defflooddelay %temptext 

Kat

Ok, so if code inside of a string_eval() string raises an error, we treat it exactly the same as if it had happened in the top-level scope. E.g. If we have try-catches, then we'd throw the exception from string_eval() up to the caller, and so on.

If we have try-catches or some other sane error handling method, this works. Right now, due to the issues dcuny raised previously in his thread about try/catch, I believe that string_eval() should not do this. I do not think that an error in string_eval() should shut down the entire program and generate an ex.err file. But once we implement better error handling, then this can be changed too.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu