Re: Getting an AudioDeviceID from device unique identifier (UID)
Re: Getting an AudioDeviceID from device unique identifier (UID)
- Subject: Re: Getting an AudioDeviceID from device unique identifier (UID)
- From: Kurt Bigler <email@hidden>
- Date: Thu, 24 Apr 2003 23:54:50 -0700
on 4/24/03 11:25 AM, Jeff Moore <email@hidden> wrote:
>
It is my opinion that a proper API only returns errors when errors
>
actually occur. Errors are like C++ exceptions, they should only be
>
used when something actually went wrong. The should not be used as an
>
alternative return path for information that has a perfectly acceptable
>
return path already. Overloading things like that in an API is a bad
>
practice that my experience has shown leads to inconsistent APIs that
>
are more difficult to use and harder still to maintain over time.
I guess you are saying that kAudioDeviceUnknown is a legitimate value of the
requested property kAudioHardwarePropertyDeviceForUID. However it seems to
me it is a legitimate value only if that value can be used for something in
some conceivable extended context.
You have have multiple return paths for information, and one of those return
paths returns an error code. In my book the error code is always the
"master" return path if there is more than one, so that it often is optional
for the implementation whether other returned values are even defined when
the error return value indicates an error. This may not be universal.
However, the caller can expect to learn from the error code whether anything
went wrong during the call. If kAudioDeviceUnknown can not be used for
anything, then saying there was no error is a little abstract.
If AudioHardwareGetProperty is really a totally general data-driven function
that sees no error in this process, because in fact, the value
kAudioDeviceUnknown was already stored somewhere, that sounds like a
legitimate argument for no error code, but it is still an argument based
more on knowledge of the implementation than on design of the API, as seen
from the outside.
So it would seem to me that the issue hinges on the potential utility of
kAudioDeviceUnknown, from _outside_ of CoreAudio.
On the other hand if there are _hundreds_ of these kinds of null values
being passed around internally and returned through bunches of get-property
interfaces, then maybe the users of the API must be exposed to these
considerations of the implementation.
-Kurt Bigler
>
In this case no error has occurred. The AudioDeviceID that matches any
>
UID that doesn't exist is kAudioDeviceUnknown. The fact that the HAL
>
wasn't returning kAudioDeviceUnknown in those cases was a bug.
>
>
On Thursday, April 24, 2003, at 10:32 AM, Sean McBride wrote:
>
>
> B.J. Buchalter (email@hidden) wrote on Thu, 24 Apr 2003 13:02:45
>
> -0400:
>
>
>
>> Cool! It is definitely better to return a sentinel value if the
>
>> device is
>
>> not found. But I still don't understand why it is not appropriate to
>
>> return
>
>> an error in this case. Basically, I am using this API to say "Find
>
>> This
>
>> Thing For Me". If you can't find it, shouldn't you return an error
>
>> like
>
>> "kAudioDeviceNotFoundError" or "kGUIDDoesNotExistError" -- sort of
>
>> like the
>
>> File Manager returns fnfError (-43) if you try to open a file that
>
>> does not
>
>> exist? Why is it not an error to ask for the device ID of a device
>
>> that does
>
>> not exist in the system?
>
>
>
> I agree. It also makes AudioHardwareGetProperty() harder to use,
>
> because
>
> one has to check BOTH the error and the device id to see if it
>
> succeeded.
>
> I'd much rather check only one... Reminds me of this:
>
>
>
> h = NewHandle()
>
> if ((h != nil) && (MemError() != noErr))
>
> ...
>
>
>
> Which I've seen a lot....
>
>
>
>
>
> --
>
> ____________________________________________________________
>
> Sean McBride, B. Eng email@hidden
>
> Mac Software Designer +1-514-822-6000
>
> Matrox Electronic Systems Ltd. Montrial, Quibec, Canada
>
> _______________________________________________
>
> coreaudio-api mailing list | email@hidden
>
> Help/Unsubscribe/Archives:
>
> http://www.lists.apple.com/mailman/listinfo/coreaudio-api
>
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.