DOC-1048 Add crash processor (#183)

Author: asimms41

modules/ROOT/nav.adoc

@@ -135,6 +135,7 @@
 *** xref:components:processors/command.adoc[]
 *** xref:components:processors/compress.adoc[]
 *** xref:components:processors/couchbase.adoc[]
+*** xref:components:processors/crash.adoc[]
 *** xref:components:processors/decompress.adoc[]
 *** xref:components:processors/dedupe.adoc[]
 *** xref:components:processors/for_each.adoc[]

modules/components/pages/processors/crash.adoc

@@ -0,0 +1,25 @@
+= crash
+:type: processor
+:categories: ["Utility"]
+
+Stops the current pipeline process with a fatal log message. You can use xref:configuration:interpolation.adoc#bloblang-queries[function interpolations] to define the log message, including the message contents and metadata that caused the fatal error.
+
+```yml
+# Configuration fields, showing default values
+label: ""
+crash: "" # No default (required)
+```
+This processor is useful for detecting unhandled errors during development and testing. For more information about common patterns for trapping errors, see xref:configuration:error_handling.adoc[Error Handling].
+
+== Fields
+
+=== `crash`
+
+Define the fatal log message that is written when an unhandled error occurs. This field supports xref:configuration:interpolation.adoc#bloblang-queries[function interpolations].
+
+```
+# Examples
+
+crash: "Processor ${!error_source_label()} failed due to: ${!error()}"
+
+```

modules/configuration/pages/error_handling.adoc

@@ -3,7 +3,12 @@
 
 Redpanda Connect supports a range of xref:components:processors/about.adoc[processors], such as `http` and `aws_lambda`, that may fail when retry attempts are exhausted. When a processor fails, the message data continues through the pipeline mostly unchanged, except for the addition of a metadata flag, which you can use for handling errors.
 
+ifndef::env-cloud[]
+This topic explains some common error-handling patterns, including dropping messages, recovering them with more processing, and routing them to a dead-letter queue. It also shows how to combine these approaches, where appropriate, and provides a method for <<logging-fatal-errors, trapping unhandled errors>>.
+endif::[]
+ifdef::env-cloud[]
 This topic explains some common error-handling patterns, including dropping messages, recovering them with more processing, and routing them to a dead-letter queue. It also shows how to combine these approaches, where appropriate.
+endif::[]
 
 == Abandon on failure
 
@@ -95,6 +100,22 @@ pipeline:
           root.meta.error = error()
 ----
 
+ifndef::env-cloud[]
+=== Logging fatal errors
+
+During development and testing, you can use the xref:components:processors/crash.adoc[`crash` processor] to halt pipeline execution and log a fatal message when an unhandled error occurs. Use Bloblang functions to customize the message. For example:
+
+[source,yaml]
+----
+pipeline:
+  processors:
+  - resource: processor_1 # Processor that might fail
+  - catch:
+    # Writes a custom fatal log message
+    - crash: "Processing failed at ${!error_source_label()} due to: ${!error()}"
+----
+endif::[]
+
 == Attempt until success
 
 To process a particular message until it is successful, try using a xref:components:processors/retry.adoc[`retry`] processor: