bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error handling question


From: Marc Herbert
Subject: Re: Error handling question
Date: Tue, 10 Nov 2009 09:53:31 +0000
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Chris F.A. Johnson a écrit :

>     It isn't desirable. However, commands will sometimes fail; they
>     are intended to fail. Their failure provides necessary information
>     to the script.

Because it lacks proper exceptions, the language is indeed creating a
confusion between exceptional errors and normal return values. But I
found it surprisingly easy to deal with this confusion in practice.


>     For example, if you want to know whether user 'john' is in the
>     password file:
> 
> grep -q ^john: /etc/passwd
>
> You want to get the return code and execute code depending on the result

I do.

> (which can be 0, 1 or >1; 'if grep ...' is not adequate).

I find "if grep ..." adequate. Ignoring >1 here is just another small
hole in the "set -e" safety net (and it will log an error message).

In the few cases where I am really afraid of exceptional errors in a test
I can check the pre-conditions by myself. For instance:

 set -e
  ...
 [ -r /etc/passwd ] || fatal "could not read /etc/passwd"
 if grep -q ^john: /etc/passwd; then ...


But honestly, how many times in real life have you seen code actually
checking for errors of commands as simple as "grep /etc/passwd" ?


>     Then you are not taking advantage of the power of the shell. Using
>     a return code provides more than a two-way branch.

I do not consider exceptions as an actual branch, which makes most
commands "two-way branch" or less. Whenever I want to return something
more complex than 0 / 1 then I do not use "return" at all but "printf"
for instance.  An integer is too poor anyway; so I use exit statuses
only for simple boolean tests xor exceptions. The only minor issue is
that it is not possible for boolean tests to "throw exceptions": each
boolean test creates a small hole in the safety net. I can live with
that.

Do you have an other example than "grep" maybe?


>> Ignoring errors should be the exception and not the rule.
> 
>     Not using set -e does not imply ignoring errors; one *uses*
>     errors.

For the clarity of this discussion could you please refrain to confuse
exceptional errors with normal return values of tests? I know that the
design of the language creates this confusion in the first place, but I
think the documentation does not and sticks to the English meaning. See
for instance "man grep":

EXIT STATUS
The following exit values are returned: 
0
  One or more lines were selected. 
1
  No lines were selected. 
>1
  An ERROR occurred.


Cheers,

Marc





reply via email to

[Prev in Thread] Current Thread [Next in Thread]