fix(docs): Update docs for try catch actions.

packages/docs/concepts/events-and-actions.yaml

@@ -28,7 +28,9 @@ _ref:
             - Events are triggered when something happens on a page, like clicking a button or loading a page.
             - A list of actions are executed sequentially by a triggered event.
             - If an action errors, the actions that follow are skipped.
+            - Action errors can be handled by providing a list of `try` and `catch` actions to the event.
             - Operators used in action `params` are evaluated right before the action is executed.
+            - The [`_actions`](/_actions)) operator is available for sequential actions to use the values returned from preceding actions in the chain.
             - Actions have a `skip` field that can be used to skip action execution.
             - The `onInit` event is triggered the first time a context is mounted and keeps the page in loading until all actions have finished.
             - The `onEnter` event is triggered the every time a context is mounted and keeps the page in loading until all actions have finished.
@@ -40,13 +42,13 @@ _ref:
 
             Blocks can define _events_ which the block can trigger when something happens on the page, like a button being clicked, an input's value being modified or a page being loaded. Some examples are `onClick` on a [`Button`](/Button) or `onEnter` on a [`PageHeaderMenu`](/PageHeaderMenu) block.
 
-            _Actions_ are tasks that can be executed, like calling a request, linking to a new page or changing a value in state. An array of actions can be defined for an event defined by a block. If that event gets triggered, those actions will execute sequentially. If any actions error while executing, the actions that follow it won't be executed.
+            _Actions_ are tasks that can be executed, like calling a request, linking to a new page or changing a value in state. An array of actions can be defined for a event on a block. If that event gets triggered, those actions will execute sequentially. If any actions error while executing, the actions that follow it won't be executed, however, `catch` actions chain can be defined on a event to trigger when a error in a chain of actions occurs.
 
             Each action has an `id`, unique to that action chain, and a `type` field which are required.
 
-            Actions can have a `params` field for specifying input parameters when executing the action. Operators used in action `params` will be evaluated right before the action is executed. Some events might have data relating to that event, like what the new value of an input is, or the row that was clicked in a table. The `event` object can be used in the action using the [`_event`](/_event) operator.
+            Actions can have a `params` field for specifying input parameters when executing the action. Operators used in action `params` will be evaluated right before the action is executed. Some events might have data relating to that event, like what the new value of an input is, or the row that was clicked in a table. The `event` object can be used in the action using the [`_event`](/_event) operator. Some actions also return values which can be passed to preceding actions in the same action chain using the [`_actions`](/_actions) operator.
 
-            Actions can also have a `skip` field. Operators in the `skip` field are also evaluated before an action is executed, and if the evaluated result is `true`, that action is skipped and the next action is executed.
+            Actions can also have a `skip` field. Operators in the `skip` field will be evaluated before an action is executed, and if the evaluated result is `true`, that action is skipped and the next action is executed.
 
             # Action Schema
 
@@ -85,12 +87,47 @@ _ref:
             ```
             # The actions object
 
-            When an event is triggered each completed action writes its response to the actions object under the action id object key. Thus all following actions in a event action list has access to the response of all preceding actions in the same event list through the [`_actions`](/_actions) operator.
+            When events are triggered, each completed action writes its response to the actions object under the action id object key. Thus all following actions in a event action list have access to the responses of all preceding actions in the same event list through the [`_actions`](/_actions) operator.
 
             # The event object
 
             When events are triggered, the can provide a data object describing the event (e.g. a description of the clicked item or uploaded file). This data object can be accessed using the [`_event`](/_event) operator in an action definition.
 
+            # Catching action errors
+
+            If one action in the chain of event actions fails by throwing an error, the actions in the list following the failed action will not be executed. To handle any errors thrown by an action, Lowdefy event actions can be provided as lists of `try` and `catch` actions.
+
+            The schema for passing actions to Lowdefy events is:
+            ```
+              (eventName: action[])
+              (eventName: {
+                try: action[],
+                catch?: action[],
+              })
+            ```
+
+            ###### Event try catch actions example for dealing with action errors:
+            ```yaml
+            - id: block_with_actions
+              type: Block
+              properties:
+                # ...
+              events:
+                onEvent1:
+                  try:
+                    - id: action1
+                      type: ActionType1
+                      params:
+                        # ...
+                    - id: action2
+                      type: ActionType2
+                  catch:
+                    - id: unsuccessful
+                      type: ActionType1
+                      params:
+                        # ...
+            ```
+
             # Context initialisation events
 
             Four events are always defined for [`context`](/context) type blocks, called in the following order: