M
marian.edu
Guest
Actually, not sure how difficult that would be for you guys to implement but adding an error-object property to the error-status system handle sounds like a great idea… then existing properties/methods (error-num, error-status, get-message) can simply use that object if valid. It will be the same as before, this is only set when no-error is used on a statement and it keeps on till the next statement with no-error. That way non-structured error handling can get access to the call-stack (as requested by Henri, I think) and we fix the AppError 
Probably setting error-status:error to false should completely reset the error system handle - aka, also delete the error-object instance if any. I wonder how do you keep the error-object instance alive and not being garbage collected but probably the reference in error-status system handle will still count as a reference and hence preventing it from being flushed away. A new statement with no-error would clear the previous error, that might leave one with references to invalid object if saved in a variable so it might worth mentioning it in the notes section. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212
Continue reading...
Probably setting error-status:error to false should completely reset the error system handle - aka, also delete the error-object instance if any. I wonder how do you keep the error-object instance alive and not being garbage collected but probably the reference in error-status system handle will still count as a reference and hence preventing it from being flushed away. A new statement with no-error would clear the previous error, that might leave one with references to invalid object if saved in a variable so it might worth mentioning it in the notes section. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212Continue reading...