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

Re: 19981007: NetCDF java stuff

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 19981007: NetCDF java stuff
  • Date: Thu, 15 Oct 1998 18:57:39 -0600
>From: address@hidden (Dan Schmitt)
>Subject: NetCDF java stuff
>Organization: .
>Keywords: 199810072103.PAA18508
>
>
>
> Hi,
>
>       Great software.

Thanks.

> After a few days of messing around
> with the java interface to the netcdf stuff, I had a few
> questions.  The netcdf interface doesn't seem to have a
> getDimension, so you have to grab the set first, and then
> get the dimension. Not a show stopper, but sort of weird
> when the variables and attributes both have a "get the
> individual" call.

What about
public Dimension DimensionSet.get(String name) ?

The design pattern is like this
DimensionSet, AttributeSet and VariableSet are
designed 'as if' they were generated from a 'Set' template.
Except there is no explict VariableSet. Netcdf extends VariableSet,
It is a VariableSet containing and associated DimensionSet and an
AttributeSet.

So your question is, why do we give you the convenience function

public Attribute Netcdf.getAttribute(String name)
        { return getAttributes.get(name)}

and not getDimension().

The answer is access pattern and frequency of use.
I think people rarely need to get a single dimension by name,
usually when you are looking at the dimensions, you are interested in
the whole shebang. Correct me if I'm wrong.
Attributes, being key-value pairs, are much more often looked up
by name.

>       Are there any plans to implement some Exceptions?
> Doing try/catch on: VariableNotFound, DimensionNotFound,
> AttributeNotFound, WrongNumberOfDimensions, and
> DimensionOutOfBounds seems much cleaner than checking to
> see if the pointer is null after each call.

There are really two questions here.
We explictly have avoided any package-specific exceptions.
The functions which return null follow the pattern of other
java.* classes like the Container framework and Hashtable.

-glenn