Add errexit, inherit_errexit

Also amended related notes in `docs/`.

See comments and `docs/error-handling.md` on why.

1 files changed, 28 insertions, 2 deletions

diff --git a/docs/error-handling.md b/docs/error-handling.md
index 483123f..27d8054 100644
--- a/docs/error-handling.md
+++ b/docs/error-handling.md
@@ -11,6 +11,11 @@
 
 ## Limitations
 
+### Introductory notes
+
+* Much of the below is from empirical evidence (aka testing).
+
+
 ### Backgrounded process
 
 * An error in a backgrounded process (e.g., `false &`) is ignored by the
@@ -59,14 +64,35 @@
   stack trace to be printed in the current [(sub-)](subshell.md)shell, but
   only a simple message mentioning the file and line number.
     * If there is no subshell involved, no stack trace is printed at all.
-    * Note that unset variable errors are also caught in
-      `declare var=$undef_var` (compare [Subshell section](#Subshell)).
+    * Note that unset variable errors are generally also caught in
+      `declare var=$undef_var` and `true $undef_var`.
+        * Compare [Subshell section](#Subshell).
+        * This does not hold if the shell is interactive (`bash -i`).
     * This is arguably not a big problem; such errors should mostly be quickly
       spotted by simple testing (or some static analysis tool).
         * Exceptions: Usage of `declare -n` and `eval` with dynamic variable
           names.
 
 
+### Array variables
+
+* Attempting to assign `var[0]=(foo bar)` or `var['x']=(foo bar)` (where
+  `$var` is an array variable or associative array variable, respectively)
+  causes an error to be printed instead of a stack trace in the innermost
+  (sub-)shell.
+    * Compare behaviour of [unset variables](#Unset_variables).
+    * See also `src/basic.bash#errexit`.
+* Attempting to assign `var['x']=foo` where `$var` is not an associative array
+  variable, has weird behaviour:
+    * In any case, the [(sub-)](subshell.md)shell where the error originally
+      occurs does not print a stacktrace, but a simple error message.
+    * If at least one subshell is involved, all but the lowest subshell print
+      a stack trace and all (sub-)shells exit correctly.
+    * If no subshell is involved, the error message is printed, but execution
+      is not aborted.
+    * Note that unlike for the preceding case, `set -o errexit` is irrelevant.
+
+
 ### Pipes
 
 * A pipeline is considered an error iff the last command returns non-zero.