Raise error in a Bash script

I want to raise an error in a Bash script with message "Test cases Failed !!!". How to do this in Bash?

For example:

if [ condition ]; then
    raise error "Test cases failed !!!"
fi

This depends on where you want the error message be stored.

You can do the following:

echo "Error!" > logfile.log
exit 125

Or the following:

echo "Error!" 1>&2
exit 64

When you raise an exception you stop the program's execution.

You can also use something like exit xxx where xxx is the error code you may want to return to the operating system (from 0 to 255). Here 125 and 64 are just random codes you can exit with. When you need to indicate to the OS that the program stopped abnormally (eg. an error occurred), you need to pass a non-zero exit code to exit .

As @chepner pointed out, you can do exit 1 , which will mean an unspecified error.


Basic error handling

If your test case runner returns a non-zero code for failed tests, you can simply write:

test_handler test_case_x; test_result=$?
if ((test_result != 0)); then
  printf '%sn' "Test case x failed" >&2  # write error message to stderr
  exit 1                                  # or exit $test_result
fi

Or even shorter:

if ! test_handler test_case_x; then
  printf '%sn' "Test case x failed" >&2
  exit 1
fi

Or the shortest:

test_handler test_case_x || { printf '%sn' "Test case x failed" >&2; exit 1; }

To exit with test_handler's exit code:

test_handler test_case_x || { ec=$?; printf '%sn' "Test case x failed" >&2; exit $ec; }

Advanced error handling

If you want to take a more comprehensive approach, you can have an error handler:

exit_if_error() {
  local exit_code=$1
  shift
  [[ $exit_code ]] &&               # do nothing if no error code passed
    ((exit_code != 0)) && {         # do nothing if error code is 0
      printf 'ERROR: %sn' "$@" >&2 # we can use better logging here
      exit "$exit_code"             # we could also check to make sure
                                    # error code is numeric when passed
    }
}

then invoke it after running your test case:

run_test_case test_case_x
exit_if_error $? "Test case x failed"

or

run_test_case test_case_x || exit_if_error $? "Test case x failed"

The advantages of having an error handler like exit_if_error are:

  • we can standardize all the error handling logic such as logging, printing a stack trace, notification, doing cleanup etc., in one place
  • by making the error handler get the error code as an argument, we can spare the caller from the clutter of if blocks that test exit codes for errors
  • if we have a signal handler (using trap), we can invoke the error handler from there
  • Related posts

  • Error handling in Bash
  • Are there any standard exit status codes in Linux?
  • BashFAQ/105 - Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?
  • Equivalent of __FILE__ , __LINE__ in Bash
  • Is there a TRY CATCH command in Bash
  • To add a stack trace to the error handler, you may want to look at this post: Trace of executed programs called by a Bash script
  • Ignoring specific errors in a shell script
  • How do I manage log verbosity inside a shell script?
  • How to log function name and line number in Bash?
  • Is double square brackets [[ ]] preferable over single square brackets [ ] in Bash?

  • There are a couple more ways with which you can approach this problem. Assuming one of your requirement is to run a shell script/function containing a few shell commands and check if the script ran successfully and throw errors in case of failures.

    The shell commands in generally rely on exit-codes returned to let the shell know if it was successful or failed due to some unexpected events.

    So what you want to do falls upon these two categories

  • exit on error
  • exit and clean-up on error
  • Depending on which one you want to do, there are shell options available to use. For the first case, the shell provides an option with set -e and for the second you could do a trap on EXIT

    Should I use exit in my script/function?

    Using exit generally enhances readability In certain routines, once you know the answer, you want to exit to the calling routine immediately. If the routine is defined in such a way that it doesn't require any further cleanup once it detects an error, not exiting immediately means that you have to write more code.

    So in cases if you need to do clean-up actions on script to make the termination of the script clean, it is preferred to not to use exit .

    Should I use set -e for error on exit?

    No!

    set -e was an attempt to add "automatic error detection" to the shell. Its goal was to cause the shell to abort any time an error occurred, but it comes with a lot of potential pitfalls for example,

  • The commands that are part of an if test are immune. In the example, if you expect it to break on the test check on the non-existing directory, it wouldn't, it goes through to the else condition

    set -e
    f() { test -d nosuchdir && echo no dir; }
    f
    echo survived
    
  • Commands in a pipeline other than the last one, are immune. In the example below, because the most recently executed (rightmost) command's exit code is considered ( cat ) and it was successful. This could be avoided by setting by the set -o pipefail option but its still a caveat.

    set -e
    somecommand that fails | cat -
    echo survived 
    
  • Recommended for use - trap on exit

    The verdict is if you want to be able to handle an error instead of blindly exiting, instead of using set -e , use a trap on the ERR pseudo signal.

    The ERR trap is not to run code when the shell itself exits with a non-zero error code, but when any command run by that shell that is not part of a condition (like in if cmd , or cmd || ) exits with a non-zero exit status.

    The general practice is we define an trap handler to provide additional debug information on which line and what cause the exit. Remember the exit code of the last command that caused the ERR signal would still be available at this point.

    cleanup() {
        exitcode=$?
        printf 'error condition hitn' 1>&2
        printf 'exit code returned: %sn' "$exitcode"
        printf 'the command executing at the time of the error was: %sn' "$BASH_COMMAND"
        printf 'command present on line: %d' "${BASH_LINENO[0]}"
        # Some more clean up code can be added here before exiting
        exit $exitcode
    }
    

    and we just use this handler as below on top of the script that is failing

    trap cleanup ERR
    

    Putting this together on a simple script that contained false on line 15, the information you would be getting as

    error condition hit
    exit code returned: 1
    the command executing at the time of the error was: false
    command present on line: 15
    

    The trap also provides options irrespective of the error to just run the cleanup on shell completion (eg your shell script exits), on signal EXIT . You could also trap on multiple signals at the same time. The list of supported signals to trap on can be found on the trap.1p - Linux manual page

    Another thing to notice would be to understand that none of the provided methods work if you are dealing with sub-shells are involved in which case, you might need to add your own error handling.

  • On a sub-shell with set -e wouldn't work. The false is restricted to the sub-shell and never gets propagated to the parent shell. To do the error handling here, add your own logic to do (false) || false (false) || false

    set -e
    (false)
    echo survived
    
  • The same happens with trap also. The logic below wouldn't work for the reasons mentioned above.

    trap 'echo error' ERR
    (false)
    
  • 链接地址: http://www.djcxy.com/p/97038.html

    上一篇: 用于C ++ / C#/ Java程序员的最简单的Shell

    下一篇: 在Bash脚本中引发错误