Re: Differentiating false from fatal

[Jon Seymour]

On Wed, Sep 10, 2008 at 9:32 AM, Dan Stromberg <dstromberglists@gmail.com>wrote:

>
> Say you have a shell script, and you need it to be bulletproof.
>
> As you write it, you throw in error checking all over the place.
>
> But say you have a function that needs to return a boolean result in some
> way - call the function "bool_foo" for the sake of discussion.  Further
> assume that bool_foo will sometimes fail to return a result, and it's
> defined with:
>
> function bool_foo
> (
> xyz
> )
>
> ...and not function bool_foo
> {
> xyz
> }
>
> ...so that bool_foo's variables don't mess with those of other functions,
> but also making it so it cannot just exit 1 to terminate the program
> directly.


It seems to me that the mechanism already exists - use the curly brace form
of the function definition and a make a habit of using local variable
definitions within the implementation of your bool_foo's. That way bool_foo
can exit if it needs to and return a boolean otherwise.

If bool_foo delegates to other functions whose use of global variables is
unspecified and potentially undesirable, then guard the call to the those
functions with enclosing subshells as required - that's a choice you make in
bool_foo.

I agree a formal exception mechanism would be nice, but I have found that
use of exit and the subshell feature does allow most exception handling
patterns to be emulated reasonably well.

jon seymour.