Remove error handling flow dev section

Author: knolleary

_includes/toc-developing-flows.html

@@ -5,7 +5,6 @@
             <li class="toctitle active"><a href="/docs/developing-flows/">Developing Flows</a></li>
             <li {% if page.url == "/docs/developing-flows/flow-structure" %}class="active"{% endif %}><a href="/docs/developing-flows/flow-structure">Flow structure</a></li>
             <li {% if page.url == "/docs/developing-flows/message-design" %}class="active"{% endif %}><a href="/docs/developing-flows/message-design">Message design</a></li>
-            <li {% if page.url == "/docs/developing-flows/error-handling" %}class="active"{% endif %}><a href="/docs/developing-flows/error-handling">Error handling</a></li>
             <li {% if page.url == "/docs/developing-flows/documenting-flows" %}class="active"{% endif %}><a href="/docs/developing-flows/documenting-flows">Documenting Flows</a></li>
         </ul>
         <hr>

docs/developing-flows/error-handling.md

@@ -98,3 +98,18 @@ The same approach can be used when the flows might run on different operating sy
 
 The Inject and Change nodes are able to access environment variables using either the "env" option in their TypedInput. The Function node can use the `env.get()` function.
 
+### Error handling
+
+Node-RED provides the Catch and Status nodes as ways of building flows that can respond to errors. For more information about how they can be used, refer to the [user guide](/docs/user-guide/handling-errors).
+
+As there is no direct visual association between a Catch node and the nodes it targets, you should consider how to position them in order to keep the flows readable.
+
+Placing them close to the parts of the flow they correspond to can help, but you should take care not cause your flows to be come overcrowded.
+
+Although approach is to group all of the error handling flows below the main flow - making the 'good' path clearly distinct from the error paths.
+
+Giving your Catch nodes a clear name is also very important to help easily identify the scenarios they are intended to handle.
+
+Which ever approach you choose, try to be consistent across your different flows.
+
+

docs/developing-flows/flow-structure.md

@@ -39,18 +39,6 @@ into smaller, reusable components and how to customise them for different platfo
 
 [more...](message-design)
 
-### [Error handling](error-handling)
-
-**Not written yet**
-
- - How to handle errors in flows
-   - what can or cannot be caught be a Catch node
- - Where Status node can be used
- - Layout of Catch/Status nodes in relation to what they target
- - Avoiding loops
-
-[more...](error-handling)
-
 ### [Documenting flows](documenting-flows)
 
 All good code should have good documentation to match. This section looks at what

docs/developing-flows/index.md

@@ -5,6 +5,18 @@ title: Handling errors
 slug: handling-errors
 ---
 
+Whilst it is easy to create flows that do the right thing when everything works,
+it is also important to think about what could go wrong.
+
+For example, if the flow interacts with an external database or API, what happens
+if it stops responding to requests? Or what if the MQTT nodes lose their connection
+to a broker?
+
+Error handling in any application is essential to ensure these sorts of events
+are handled properly. What it means to handle the error will depend on the
+requirements of the application. You may want to try an action that failed, or
+trigger a separate alert, or maybe the error is an entirely expected event that
+is just another part of the application logic.
 
 Node-RED provides two ways for a node to report an error. It can either just
 write a message to the log or it can notify the runtime of the error and cause
@@ -22,7 +34,8 @@ There is a third sort of error that can cause the Node-RED runtime to shutdown.
 in nodes.
 
 This guide describes each of these error types in more detail and shows what can
-be done to handle them.
+be done to handle them. It also looks at how the Status events of a node can be
+used to create flows that [handle unexpected events](#handling-status-changes).
 
 
 ### Logging errors
@@ -102,6 +115,13 @@ This allows you to create error handling flows that target specific nodes and al
 have an error handler that will catch "everything else".
 
 
+#### Errors in subflows
+
+If an error is logged from inside a subflow, the runtime will first check for any
+Catch nodes inside the subflow. If there are none there, the error will propagate
+up to the flow containing the subflow instance.
+
+
 ### Uncatchable errors
 
 These are the errors a node writes to the log without notifying the runtime properly.
@@ -136,3 +156,29 @@ caused the error and raise an issue against it. This is not always easy due to t
 The stack trace provided in the Node-RED log will provide some clues as to the
 nature of the asynchronous task that hit the error, which in turn may help you
 to identify the node at fault.
+
+### Handling Status Changes
+
+Not all errors conditions will appear as error events that can be caught be a
+Catch node. For example, the MQTT nodes losing their connection will not trigger
+an error, but they will trigger a change of their status.
+
+Just as the Catch node can be used to handle error events, the Status node can
+be used to handle changes in a node's status.
+
+The message sent by the Status node includes the `status` property that gives
+information about the status and the node that triggered the event.
+
+```json
+{
+    "status": {
+        "fill": "red",
+        "shape": "ring",
+        "text": "node-red:common.status.disconnected",
+        "source": {
+            "id": "27bbb5b1.d3eb3a",
+            "type": "mqtt out"
+        }
+    }
+}
+```