Conditional continue in for loop breaks errexit in function

Question

AFAICT, having continue in for loop that calls another function breaks the errexit semantics. In the main() function, I want to continue onto the next iteration if anything fails in the build() function:

#! /usr/bin/env bash

export PS4='# ${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]}() - [${SHLVL},${BASH_SUBSHELL},$?] '
set -o xtrace
set -o errexit

build() {
  local _foo=$1

  if [ "${_foo}" -eq 1 ]; then
    false
  fi

  printf "%s with foo=%s builds ok\\n" "${FUNCNAME[0]}" "${_foo}"
}

main() {
  for i in 1 2 3; do
    build $i || continue
  done
}

main "$@"

However, continue inside the for loop causes the code to continue inside the build() function instead, removing the effect of the errexit flag:

$ ./foo.sh 
# ./foo.sh:5: () - [3,0,0] set -o errexit
# ./foo.sh:23: () - [3,0,0] main
# ./foo.sh:18: main() - [3,0,0] for i in 1 2 3
# ./foo.sh:19: main() - [3,0,0] build 1
# ./foo.sh:8: build() - [3,0,0] local _foo=1
# ./foo.sh:10: build() - [3,0,0] '[' 1 -eq 1 ']'
# ./foo.sh:11: build() - [3,0,0] false
# ./foo.sh:14: build() - [3,0,1] printf '%s with foo=%s builds ok\n' build 1
build with foo=1 builds ok
# ./foo.sh:18: main() - [3,0,0] for i in 1 2 3
# ./foo.sh:19: main() - [3,0,0] build 2
# ./foo.sh:8: build() - [3,0,0] local _foo=2
# ./foo.sh:10: build() - [3,0,0] '[' 2 -eq 1 ']'
# ./foo.sh:14: build() - [3,0,0] printf '%s with foo=%s builds ok\n' build 2
build with foo=2 builds ok
# ./foo.sh:18: main() - [3,0,0] for i in 1 2 3
# ./foo.sh:19: main() - [3,0,0] build 3
# ./foo.sh:8: build() - [3,0,0] local _foo=3
# ./foo.sh:10: build() - [3,0,0] '[' 3 -eq 1 ']'
# ./foo.sh:14: build() - [3,0,0] printf '%s with foo=%s builds ok\n' build 3
build with foo=3 builds ok

As you can see on the line with the printf, the exit code of the previous line, the false, is indeed 1 (the third number inside the bracket in front of it), so it is running as if errexit wasn't in place:

# ./foo.sh:14: build() - [3,0,1] printf '%s with foo=%s builds ok\n' build 1

I've confirmed that removing the || continue makes the shell exit when i=1, so the errexit is passed onto the subhshell/function.

Any help would be much appreciated.

Versions

~ $ bash --version                                                            
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)

Update

Lots of good answers as to why this is. As for how to solve it, I've found this solution to be the easiest to make the script to what I want: Changing the false to:

false || return $?

The drawback of course, is that I'll have to do that for all the commands the function calls out to. I might have to go back to my old approach of using a run() wrapper, which executes the passed command, checks the return code of it and fails the script accordingly. Doing what you would expect errexit to do, I suppose :-)

Answer 1

This seems to match the description of -e/-errexit in the bash documentation:

The shell does not exit if the command that fails is part of the command list immediately following a while or until keyword, part of the test in an if statement, part of any command executed in a && or || list except the command following the final && or ||, any command in a pipeline but the last, or if the command’s return status is being inverted with !.
[...]

If a compound command or shell function executes in a context where -e is being ignored, none of the commands executed within the compound command or function body will be affected by the -e setting, even if -e is set and a command returns a failure status.

This has been covered in this stackoverflow question, which links to this email with the following text:

> My initial gripe about errexit (and its man page description) is that the 
> following doesn't behave as a newbie would expect it to:
> 
> set -e
> f() {
>   false
>   echo "NO!!"
> }
> f || { echo "f failed" >&2; exit 1; }

Indeed, the correct behavior mandated by POSIX (namely, that 'set -e' is
completely ignored for the duration of the entire body of f(), because f
was invoked in a context that ignores 'set -e') is not intuitive.  But
it is standardized, so we have to live with it.

The POSIX description of -e says:

-e
When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit.

Answer 2

From the manual [emphasis mine]:

errexit

Same as -e.

-e

Exit immediately if a pipeline […], which may consist of a single simple command […], a list […], or a compound command […] returns a non-zero status. The shell does not exit if the command that fails is part of […] any command executed in a && or || list except the command following the final && or ||, […]

[…]

If a […] shell function executes in a context where -e is being ignored, none of the commands executed within the […] function body will be affected by the -e setting, even if -e is set and a command returns a failure status. […]

In your build $i || continue build is a shell function that executes in a context where -e is being ignored. false is a command executed within the function body, it is not affected by the -e setting and therefore it doesn't even prevent printf from running.

Removing the || continue and invoking just build $i places every part of the function in a context where -e is not being ignored, so the entire code exits because of false and just after false (without getting to printf).

It seems errexit is a global setting that (when not being ignored) terminates the entire script. One cannot (or at least cannot easily) make it terminate a function but not the entire script.