Re: [Help-bash] trap when expected return value may be non-zero?

[Bob Proulx]

adrelanos wrote:
> I have a global trap, but in one function I am expecting a non-zero
> return code. Example:
> 
> trap "error_handler" ERR INT TERM

I can't really define it but it makes me squirm to see ERR bundled
together with INT and TERM.  (And if you are catching INT and TERM why
not HUP and QUIT?  Seems like an omission.)

If you search the lists you will find much discussion and opinions
about 'set -e'.  It is a very polarized issue.  People either love it
or hate it.  And ERR is right in the middle of it too.

The problem I see above is that ERR isn't really bundled to INT or
TERM and so trying to bundle them together feels incorrect to me.  If
you are just doing something for debugging that is one thing.  But I
would never want to see that in production code.  If that were passed
through my keyboard the first thing I would do is remove the ERR
trap.  That is just my opinion and style and it differs from others
who like set -e behavior.

I recommend avoiding ERR and set -e.  There are limited times when
they are useful.  But I don't think they are generally useful.  In
general their use tends to cause many problems.

Here is a reference to read up on it.

  http://mywiki.wooledge.org/BashFAQ/105

> examplefunct() {
>    # code...
> 
>    service someservice status
>    returncode="$?"
> 
>    # more code...
> }
> 
> When service return a non-zero value, the error_handler is called.

Right.  Because you have set the ERR trap.

> So I have to work around it. Example:

So you are working around your own code?  I think now you see the
point of why doing it that way feels bad.  It feels like you are
working against yourself.

> trap "error_handler" ERR INT TERM
> 
> examplefunct() {
>    # code...
> 
>    trap "" ERR INT TERM
>    service someservice status
>    local returncode="$?"
>    trap "error_handler" ERR INT TERM
> 
>    # more code...
> }
> 
> Well, it works, but thats not so pretty.

And you have disabled INT and TERM during that same time period.  If
you needed them otherwise then you have a bug because during that time
period they are disabled.  And if you don't need them then it is still
a bug because you have them otherwise.

> Basically, I just want to the trap being called in case something really
> unexpected happens. Most times I use traps as a way to find bugs in my
> scripts. In this case, for example if "service" wouldn't exist (not in
> $PATH or whatever) or if "someservice" wouldn't exist..

If I am checking status then I will expect a good confirmation of a
running service and anything that isn't that will be interpreted that
the service is offline.

If I am starting a service then I will explicitly check for errors and
handle them for that start.  It is unlikely that a generic any-failure
type of exception handler will know what to do correctly.

Bob