NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Dennis,This issue -- how a netCDF client can get detailed error messages from a remote OPeNDAP server -- has been floating around for a long time. In my opinion it is a situation where it is OK to go outside the previously published netCDF API as follows:
1. the netCDF API returns NC_EDAPSVC, indicating that there was a DAP
server-side error. This is sufficient for many clients. End of
story for them.
2. but for a client that *wants* to know more details it would be
desirable to have access we could provide a new API call
detailedMessage = tellMeMoreAboutTheOpendapServerSiderError();
Through this call the client can learn whatever it is that the remote
server has sent back to the underlying library code. The
standardization of that message imposed by HTTP and DAP, not by NetCDF.
I realize that this may look like a can of worms in some respects -- e.g. how and where do you document this call if it is not regarded as a part of the netCDF API? That's a detail to consider .. but I hope not something that would torpedo an important functionality. In some situations we have to recognize that remote data access has different needs from local netCDF files. This seems like one of them.
- Steve ============================ Ansley Manke wrote:
hi -I meant this not to dictate words, but just as a general comment that friendly human-readable error messages are desirable; something that will be meaningful to the end-user. Also that the application code should be able to get those messages as a string to use in its own error handling procedures.Ansley Dennis Heimbigner wrote:ok, I see; there is a defined error code for server side errors. It is NC_EDAPSVC, and has the associated string: "NetCDF: DAP server side error" I can certainly modify the error string to include the ... Please contact the adminstrator " to the message. =Dennis Ansley Manke wrote:Hi Dennis, Dennis Heimbigner wrote:I'm thinking along the lines of the NF_STRERROR(status) call which takes an error code and returns an error string. It might be that the string would be "error at the data server. Please contact the administrator ..." Returning some words is better thanI dont think I follow this comment. The log output is generally for debugging purposes and I would not expect ordinary users to use it. Rather, they will see a netcdf error such as NC_SVCERR indicating a server side error. If they encounter that, then someone more sophisticated can turn on logging and see the details. The problem is that there is currently no way to pass more detailed info thru the netcdf API.** unknown netCDF error code: -69In any case, the error messages available after "setenv OCLOGFILE" are highly useful. This output received by Ferret is much more helpful than the error code alone. Can things be set so that the application can get this kind of message? Could the Warnings and Errors be separated so that we could get one and not the other?=Dennis Heimbigner_______________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
-- Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@xxxxxxxx 7600 Sand Point Way NE, Seattle, WA 98115-0070 ph. (206) 526-6080, FAX (206) 526-6744 "The only thing necessary for the triumph of evil is for good men to do nothing." -- Edmund Burke
netcdfgroup archives: