D
David Abdala
Guest
I'm certain I wasn't clear enough. I think (now) the problem resides in STOP having multiple meanings. I think this is the right opportunity to fix this, and make STOP a unified concept of: execution can't continue due to a general failure condition with AVM, stack is poped up to a safe state, where execution can continue. So, there are several ERRORs that raised the STOP condition, that now should not do that, they should be just ERRORs following the same rules as any other ERROR. In the other hand you have the STOP condition, that can be set up by a STOP statement, Ctrl+C, a Memory Access Violation, etc. that behaves exactly as STOP does today, ignoring CATCH, and ignoring FINALLY, up to a safe level, this requires explicit coding to be handled, as shouldn't be trapped by "normal CATCH". There is a "middle ground" approach, where a STOP condition stops execution up to a safe stack level, and at that level it becomes an STOP-ERROR that can be CATCH by normal error handling. I believe the latter is the way to go, as almost "honors" current behavior, and also "honors" error handling behavior.
Continue reading...
Continue reading...