Re: Returning zero or empty string for unsupported objects

["C. M. Heard" <heard@pobox.com>]

Greetings,

I think Dave's analysis is right on ... it is not necessarily wrong
for an object definition to specify that a special value be returned
to indicate that a function isn't supported.  If we did make such a
blanket rule I think we'd be guilty of creating an unnecessary rule.
I say let this remain a design choice.  (Of course, it's always
fair for a reviewer to ask a designer to consider alternatives ... I
just don't think this one should be elevated to the status of a
SHOULD or MUST.)

//cmh

On Thu, 6 Nov 2003, David T. Perkins wrote:
> HI,
> 
> It's OK to return a "special value", as long as the special value
> is not one of the normal values. For counters, there is no
> special value, and, thus, the only way to indicate that the
> value is not supported is to return "noSuch".
> 
> In all cases, it's a tradeoff of "can useful management apps
> be written" when an incomplete set of attribute values
> are available for an instance versus the cost of writing
> the app that can cope with a partial set of attribute
> values.
> 
> On Thu, 6 Nov 2003, Wijnen, Bert (Bert) wrote:
> > I know that we tell people not to do so and instead
> > return a nuSuchInstance or noSuchObject.
> > 
> > But I cannot find text in an RFC that says that such is bad.
> > 
> > Anyone else who has a ptr?
> > 
> > Thanks,
> > Bert 
> 
> Regards,
> /david t. perkins