On Mon, 25 Oct 2010 16:05:12 -0400, Jameson Rollins <jroll...@finestructure.net> wrote: > Let's say I'm writing a bash script. It will make 5 calls. Three of > the calls are expected to return zero on success, one is expected to > return 1 on success, and one whose return code I don't care about. > Here's this script written with set -e: > > #!/bin/bash > set -e > call0 > call1 > call2 > call3 || ret=$? > if ((ret != 1)); then > exit 1 > fi > call4 || true
imagine that line 2 of the script is this: let i=$i+1 set -e FAILS and because this script was designed to protect your life, you perish. The end. Now imagine that your script says this instead: call0 || die oh no! Now imagine that your script says this instead: call0 || die "Could not stuff!, please edit stuff.conf" call1 || die "Could not cd to /stuff; check the stuff.conf configuration" etc. > I'm honestly curious to hear what you guys see as wrong with this > reasoning. When you handle errors *yourself* instead of just falling over dead, you get to be helpful.
pgpqnx8ZjpRxh.pgp
Description: PGP signature
