I would use this structure in almost every script I write. Looking back over a previous project, this try control structure would have saved us hundreds... no wait, thousands... no wait, ten thousand script steps!
Developing top notch solutions requires error handling at every corner. The current toolkit is less than ideal and results in a lot of extra script steps. The inclusion of new script steps to support a try control structure would save a lot of time, simplifying and improving the readability of code.
The try block is a simple control structure compared to exceptions, but would fit very easily into the current error reporting paradigm. It also remains accessible and readable to developers who are just starting out.
- Some errors are trivial. The start of a try block should include a way to mute specific error numbers.
- If not the numbers of my choice, the most common trivial errors are: finding no records given a criteria, go to record [next] at end of loop, and go to related records not matching any foreign records.
- If muted inside a try structure, the step in question should no longer write a message in any log.
- If an error number is muted inside a try structure, that type of error should not trigger the "Pause on Error" condition. -- Added 2015-10-28
- Nesting should be supported. An error should advance instruction pointer to the error handling block of the current level. Manually signaling an error, just like an engine error, inside a first half of the try block triggers the error handler of that same block. However, an error error inside the error handler, which is also inside another try block, moves execution to the outer error handler.
- The Signal Error step should work, even if used outside a try block. With error capture on, it would write a log message, like any other erring step. See Logging all script errors. With error capture off, it would put up a dialog box, just like any other erring step.
Set Error Capture [On]
Try [Ignoring: 401¶101]
Perform Find [Restore; No dialog]
Set Variable [$error; Value: Get ( LastError ) ]
Set Variable [$line_no; Value: Get ( LastErrorLineNumber ) ]
If [$error = 301]
Show Custom Dialog ["Handling an issue..."]
# We don't know this one, signal but with our own number
Signal Error [-999; "Message for dialog and/or log..."]
I'm not sure about error signaling on the script stack. Current step errors don't really appear on calling scripts in a manner that is useful or coherent. Allowing error signals to propagate to an error handler in a parent script could be really useful, but this would be a more significant departure from traditional operation. On the other hand, maybe this could remain backwards compatible by only forcing the exit of a script when an error is uncaught AND the parent script is performing this script in the context of a try block.
If error reporting is going to bubble up the script stack, it should work uniformly with PSoS (waiting for completion).
New 2015-10-28: The On Error step should be optional, just like Else is to If. Developers might want to use the Try structure for the sole purpose of muting one or more error numbers. I'm not settled yet on whether the omission of the On Error section should automatically cause the error to bubble up.