Or go the other direction: stop trying to do fancy things and write simpler code that avoids errors.

  #!/bin/sh
  [ "${DEBUG:-0}" = "1" ] && set -x
  set -u
  foo="$( my-external-program | pipe1 | pipe2 | pipe3 )"
  if [ -z "$foo" ] ; then
      echo "Error: I didn't get any output; exiting!"
      exit 1
  fi
  echo "Well I got something back. Was it right?"
  if ! printf "%s\n" "$foo" | grep -q -E 'some-extended-regex' ; then
      echo "Error: '$foo' didn't match what I was looking for; exiting!"
      exit 1
  fi
  echo "Do the thing now..."

A lot of programs will either produce valid output as STDOUT, or if they encounter an error, not produce STDOUT. So for the most part you just need to 1) look for any STDOUT at all, and then 2) filter it for the specific output you're looking for. For anything else, just die with an error. If you need to find out why it didn't run, re-run with DEBUG=1.

Advanced diagnosis code won't make your program work better, but it will make it more complicated. Re-running with tracing enabled works just as well 99% of the time.

▲ maccard 3 days ago | parent | next [-]

> A lot of programs will either produce valid output as STDOUT, or if they encounter an error not produce stdout

Lots of programs produce nothing in the success case and only print in the failure case.

	▲	3 days ago \| parent [-]
		[deleted]

▲ o11c 3 days ago | parent | prev [-]

Ah yes, the old "just write non-buggy code, or at least code whose bugs are deterministic".

My solution just silently sits in the background for unexpected, unpredictable bugs.