More on netcdf C++ error handling

>> 4) Do you make calls to NcError::NcError(Behavior) to change away
>> from the default behavior? (The default behavior is 'verbose_fatal' which
>> prints a message and exits on error.)

-- address@hidden (Tom Glaess) writes:

> Yes, all of the time. It's my default to handle problems myself. I don't
> remember the syntax, but I think I use noverbose-nonfatal.

-- Tom LeFebvre <address@hidden> writes:

> Yes.  Since our system is targeted to run in a real-time environement,
> we've choosen to modify the verbose_fatal behavior to verbose_nonfatal.
> Of course, we log the problem so that it can be quickly diagnosed, but
> in real-time, we cannot allow a program to terminate unexpectedly.

The current situation, providing an object interface to the
netcdf-2 C ncopts/ncerr globals is less than optimal for a
number of reasons.
a) The default behavior (verbose_fatal) is generally unacceptable.
b) The use of globals is tricky to do right in multi-threaded programs,
hence the globals are relegated to backward compatiblity ghetto in
netcdf-3. I would prefer to avoid their use in the C++ interface.
c) In the netcdf-2 C++ implementation, there are errors which occur which
do not set the global ncerr. (They are only reported by a return code
of NcBool FALSE for the operation in question.)
d) The C++ runtime system can have errors which are "reported" in another
way (eg, exceptions or set_new_handler().
e) Uses the C library fprintf(stderr, ...) which may not mix well with an
error stream

(Points c and d could be summarized as "inconsistant error model".)

I would like to propose some options for error handling and invite your
comments. Perhaps you can think of more options. Perhaps you don't
consider the problems above that big a deal.

0) Keep things as they are.
        Advantages:
                100% backward compatible. :-)
        Disadvantages:
                (listed above)
                In particular, couples C++ interface to the deprecated
        version 2 C interface.

1) Throw exceptions. In this scenario, NcError methods would become noops and
   exceptions would be thrown from the point of error.
        Advantage:
                Consistant with the language and library specification.
        Disadvantages:
                Inconsistant implementations. (Runtime systems lack
        exception support or an consistant base class from which to
        derive our exceptions.)
                Not backward compatible. The NcBool error return indicator
                becomes extraneous in our interface. Major changes to existing
programs
        to add try blocks.


2) Return error codes.  In this scenario, NcError methods would become noops
   and most methods would return an integer error code.
        Advantages:
                Simple, consistant model which gets the info (error code)
                to the calling program with a minimum of fuss.
        Disadvantages:
                Not backward compatible.
                Errors in constructors must be handled specially.
2a) Like 2), except return error _objects_ which cast to NcBool (and/or have
operator()==, operator()!= appropriately overloaded) and contain the error
code.
        Advantages:
                Same as 2.
        Disadvantages:
                Tricky to get right. Still may require changes to existing
code.
                Still requires special handling of errors in constructors.

3) In NcError, replicate the netcdf-2 globals as static members and reimplement
   reporting method to use streams.
        Advantages:
                Backward compatible while decoupling dependency on C lib; fixes
                problem e).
        Disadvantages:
                Doesn't address global state issue. Introduces problems of
                consistancy between the C++ code base and the C code base.
                If programs mix C++ and netcdf-2 C calls, we have two sets of
                globals which need to be consistant at runtime.
3a) Just reimplement the reporting method to use streams.


So, that should be enough to get us going. I appreciate your input.

-glenn