On May 1, 2005, at 3:30 AM, Jan Schenkel wrote:
I personally prefer the try-throw-catch trinity, as it makes for cleaner code than indented if-then-else structures.
If this a switched by the user, then maybe something like this would work for a script library:
The error mode of a stack library can be set by a command. The default is "RESULT" out of respect for those new to scripting.
Major commands would check this and either return an error message in the result or throw it depending on the setting. Well, if there is an error.
Functions would check this and either throw or generate/propagate error messages. In those functions where the latter is not appropriate, they either do something reasonable or set an error state that can be checked later.
In some cases, for the purpose of speed, bad inputs might get throws from built-in operations, but they might look like library bugs to the user if not documented right.
(Hidden from the user would be a way for the developer to set a switch certain errors such as bugs get thrown so they show up with the IDE error dialog.)
Now, should the thrown errors be compatible with the IDE debug window or should they be the error messages themselves?
Dar
--
**********************************************
DSC (Dar Scott Consulting & Dar's Lab)
http://www.swcp.com/dsc/
A Sponsor of RevCon West
**********************************************_______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
