[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
- Re: Error handling question, (continued)
- Message not available
- Re: Error handling question, Jan Schampera, 2009/11/09
- Re: Error handling question, Ciprian Dorin, Craciun, 2009/11/09
- Re: Error handling question, Greg Wooledge, 2009/11/09
- Re: Error handling question, Ciprian Dorin, Craciun, 2009/11/09
- Re: Error handling question, Greg Wooledge, 2009/11/09
- Re: Error handling question, Sven Mascheck, 2009/11/09
- Re: Error handling question, Chet Ramey, 2009/11/09
- Re: Error handling question, Sven Mascheck, 2009/11/09
- Re: Error handling question, Marc Herbert, 2009/11/09
- Re: Error handling question, Chris F.A. Johnson, 2009/11/09
- Re: Error handling question,
Marc Herbert <=
- Re: Error handling question, Marc Herbert, 2009/11/10
- Re: Error handling question, Chet Ramey, 2009/11/09
- Re: Error handling question, Marc Herbert, 2009/11/10
- Re: Error handling question, Chet Ramey, 2009/11/10