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