from what you describe, - the Compiler - ON ERROR CALL - JSON Parse
all seem to be working as expected. if there is a bug, I would argue that it is in the documentation, for furnishing the wrong kind of expectations in these features. --- the alternative, to "correct" any of the aforementioned 3 elements seems like a bad idea. consider: - let the Compiler tolerate the assignment of a different type in compiled mode this undermines the whole point of compilation, to generate object symbols, control statements and operations to assembly code. it is the same as running interpreted all the time. - let the Compiler disallow the assignment of a different type JSON Parse with its current syntax would be uncompilable as it has multiple return types. - let ON ERROR CALL work for runtime errors too runtime errors are fatal by nature, there is no way to recover than to re-write the code and to re-compile. the alternative is to crash immediately. if the dialog popping up is confusing to the end-user, maybe a different, more serious looking dialog would be appropriate. one that says, the application has a bug, please contact the developer, I will crash now. - let JSON Parse have a fixed return type this means less generic commands such as JSON Parse as object, JSON Parse as text, etc. the code would look redundant and verbose for most cases where such precautions are unnecessary. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
