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

Re: 980304: Suggestion for netCDF3 ncpopt()-style routine

> To: netCDF Support <address@hidden>
> From: Charlie Zender <address@hidden>
> Subject: Suggestion for netCDF3 ncpopt()-style routine
> Organization: NCAR/CGD
> Keywords: 199803041951.MAA25862 netCDF3 ncopts
>
> Hi all,
>
> I miss the functionality of the netCDF2 ncopts/NCPOPT() routine.
> This routine allows one to easily specify that a program should abort
> execution on any netCDF error. Using only netCDF3 routines, one must
> check the return success code for each and every netCDF call in order
> to be sure no errors have occurred (correct me if I am wrong). Doing
> so requires a large amount of extra code for routines with hundreds or
> thousands of netCDF calls.

It is true that with netcdf-3 there will (or should) be more error condition
checks visible in user code than with netcdf-2.
I'll point out that the same tests were being performed in the library in
netcdf-2, so it is not "costing" anything more at runtime. In fact, because
we had to support several different styles of error handling in netcdf-2,
the tests that you put in might well be simpler and more suited to your
situation.

> Of course you have maintained backwards compatability so I can still
> use NCPOPT() in a program with netCDF3 calls. This is neither an
> elegant nor a permanant solution to the problem. My hope is you will
> add the ability to terminate a program (a la ncpopt(NCVERBOS+NCFATAL))
> to future versions of netCDF3 and beyond.

I don't think this is going to happen, and I'll try to justify why.
It was a deliberate design decision to eliminate ncopts and the associated
runtime variability of netcdf library error handling in favor of uniform
"all functions return status" approach.

The first reason is that the old default, "print a message to standard
error and exit", is not often acceptable. Sure, it might be acceptable
for a "quick look" program that just you are using, but how would you
feel about a commercial product behaving this way?

The second reason is that the old "other option" (verbose and not fatal)
is increasingly not often acceptable. We are seeing more and more GUI
based applications where printing a message to standard error is not the
right thing to do. A related problem has to do with the text of the error
messages themselves. In netcdf-2, the text was scattered all around the
the library, making internationalization of text a nightmare.

A third reason is that when you turn off verbose and fatal in netcdf-2,
so that a programmer is handling the errors himself, the detection of
error conditions was all over the map.

So we adopted a uniform error model where all the functions return a status
code, and we provide another function to convert the status code to a string.
Any "internationalization" is isolated to this nc_strerror() function.

Now, you will correctly note that we could have done the above and left
you with the ncopts choices. The reasons for doing this are more subtle
and perhaps less justifiable.  One design goal of netcdf-3 is to make it
multiprocessor or thread safe. We aren't quite there yet, but the elimination
of globals like ncopts are a step in that direction. It is tricky to properly
support global changes of behavior in a multiprocessing context. (It is
actually even a bit of problem for shared libraries.) It is especially ugly
when the
global behavior being controlled is something as fundemental as error handling.
Philosophically, error handling is generally considered program design issue,
as opposed to a runtime issue. So, we leave it up to you, the person writing
the program. The approach we have taken is consistant with many public
libraries, like the i/o systems, graphics libraries, and so on. You will admit
that our old approach, while convenient, was a bit unusal.

Thank you for using netcdf.

-glenn