throw vs the result
Dar Scott
dsc at swcp.com
Sun May 1 13:06:24 EDT 2005
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
**********************************************
More information about the use-livecode
mailing list