Sometimes errors happen. When they do, there are different ways to handle them. In LogixNG Preferences there is a setting that's used by default. But it's also possible to override this setting on an action or expression.
For new users of LogixNG, it's recommended to show dialog when errors occurs. That way, you will quickly notice the errors. The drawback with this is that all the ConditionalNGs that uses this thread will stop until the dialog is closed.
For production use, for example when you have a big layout with lots of ConditionalNGs, it's recommended to log the errors. That way, LogixNG will still continue to run, despite the error. The drawback with this is that an error might not be noticed.
This setting is available when editing an action or expression and is the default in this case. It means that if an error occurs, it will use the default setting as specified in Preferences. It's recommended to leave this setting, unless a particular action or expression needs special handling.
Show a dialog box with the error. This is recommended for new users and for ConditionalNGs that you have trouble with. Note that every ConditionalNG that's using the same thread will stop until the dialog is closed, but if you have trouble with only a few ConditionalNGs, you can put these on a separate thread to let the other ConditionalNGs to continue to run despite the dialog box.
The checkboxes can be used to prevent subsequent errors by disabling a component. The Abort button will stop the ConditionalNG. The Continue button will let it continue if possible.
Log a warning message on the JMRI System Console. Recommended for advanced users and for production use, for example when using LogixNG for large club layouts.
Log a warning message once. Recommended for errors that happens very often to not fill the log. If you have an action or expression that often causes problems, you can set that action or expression to log once.
Throw causes errors to be thrown to the upper level. It's useful if you want an error to abort execution for some levels. If you, for example, has a for loop, and you want that loop to be aborted if an error occurs in it's child, you can let the children throw the error.
Aborts the current execution of the ConditionalNG and log an error message. This is useful if an error is so severe that the current execution of the ConditionalNG must be stopped.