|
|
|
date: 7 Mar 2006 07:30:29 -0800,
group: microsoft.public.platformsdk.com_ole
back
[out] interface pointers from collections: how do you handle "not found"?
OK, say I have some sort of collection object, which owns an array of
interface pointers identified by keys. It has a method which returns an
IUnknown * or an IDispatch * as an output parameter, e.g.:
HRESULT lookup([in] BSTR key, [out, retval] IUnknown **ppval);
If the collection object finds the key, all is well, and lookup() does
a QueryInterface for IUnknown into ppval, returning QI's result (which
hopefully is S_OK, and if not, there's good reason for it).
If the collection object does not find the key, what's the best action
for it to take? Should I return an error (COLL_E_NOT_FOUND) and leave
ppval alone? Or should I set *ppval to NULL and return S_FALSE?
I need to know, both for myself as an implementor, and for an existing
scriptable program that handles general IDispatch-type COM calls as
long as they stick w/ the basic types (integers, floats, BSTRs,
IUnknown, and IDispatch)... this program was written by someone else,
who right now is assuming that [out] values which are interface
pointers are always non-NULL if the result succeeds -- so right now I
have no way of handling the not-found case in a lookup() call which
doesn't cause an error (either I cause the error intentionally by
returning an error code HRESULT, or he causes the error when I put NULL
into *ppval). The author is receptive to changes, where they make
sense...
date: 7 Mar 2006 07:30:29 -0800
author: Jason S
Re: [out] interface pointers from collections: how do you handle "not found"?
Jason S wrote:
> OK, say I have some sort of collection object, which owns an array of
> interface pointers identified by keys. It has a method which returns
> an IUnknown * or an IDispatch * as an output parameter, e.g.:
>
> HRESULT lookup([in] BSTR key, [out, retval] IUnknown **ppval);
>
> If the collection object finds the key, all is well, and lookup() does
> a QueryInterface for IUnknown into ppval, returning QI's result (which
> hopefully is S_OK, and if not, there's good reason for it).
>
> If the collection object does not find the key, what's the best action
> for it to take? Should I return an error (COLL_E_NOT_FOUND) and leave
> ppval alone? Or should I set *ppval to NULL and return S_FALSE?
First, you should set *ppval to NULL whether or not you decide to return
an error code. All [out] parameters must be reasonably initialized even
in case of failure.
Whether to return an error or success code is a design choice. COM does
not care either way. You should decide whether you consider a missing
key an error or a normal situation. E.g. index out of bounds in an
array-like collection is very likely an error. A key not found in a hash
table may or may not be considered an error, depending on intended use.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Tue, 7 Mar 2006 10:51:32 -0500
author: Igor Tandetnik
Re: [out] interface pointers from collections: how do you handle "not found"?
"Igor Tandetnik" wrote in message
news:u4CAD8fQGHA.2012@TK2MSFTNGP14.phx.gbl...
> Jason S wrote:
>> OK, say I have some sort of collection object, which owns an array of
>> interface pointers identified by keys. It has a method which returns
>> an IUnknown * or an IDispatch * as an output parameter, e.g.:
>>
>> HRESULT lookup([in] BSTR key, [out, retval] IUnknown **ppval);
>>
>> If the collection object finds the key, all is well, and lookup() does
>> a QueryInterface for IUnknown into ppval, returning QI's result (which
>> hopefully is S_OK, and if not, there's good reason for it).
>>
>> If the collection object does not find the key, what's the best action
>> for it to take? Should I return an error (COLL_E_NOT_FOUND) and leave
>> ppval alone? Or should I set *ppval to NULL and return S_FALSE?
>
> First, you should set *ppval to NULL whether or not you decide to return
> an error code. All [out] parameters must be reasonably initialized even in
> case of failure.
>
> Whether to return an error or success code is a design choice. COM does
> not care either way. You should decide whether you consider a missing key
> an error or a normal situation. E.g. index out of bounds in an array-like
> collection is very likely an error. A key not found in a hash table may or
> may not be considered an error, depending on intended use.
Best might be to have lookup return an error, but provide an alternate
function "exists" which does not (and set a proper [out, retval] boolean,
because many languages can't distinguish S_OK and S_FALSE).
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>
date: Tue, 21 Mar 2006 09:57:02 -0600
author: Ben Voigt am
|
|
