On 22 May 2014, at 07:50, Ben Kennedy <[email protected]> wrote: > If that is indeed the context in which Gerriet is receiving the error, it > sounds as though the routine generating it is assigning an inappropriate > error domain then, no? Surely it should be a CoreAudio-related domain > (specifically for the reason illustrated by this thread).
Yes and no. These errors predate NSError and error domains. NSOSStatusErrorDomain wraps all the errors that fit into the (pre-MacOS X) OSStatus error code type. So pretty much all Carbon-descended API and the few calls in CoreFoundation that return more than a BOOL are encapsulated in the single NSOSStatusErrorDomain. This includes lower-level API like CoreAudio and CoreGraphics. Would it be nicer and cleaner if the OS used a separate domain for errors from separate frameworks? Possible. In general, the easiest way to find these error codes is quoting them in Google and doing a search of "Project and Frameworks” for that number and look at whatever constant name it is. Sadly, some errors are defined sequentially in enums, so sometimes the actual number doesn’t appear in the code, in which case it gets more difficult. CoreAudio’s odd choice of redefining the integer OSStatus as a FourCharCode also doesn’t make finding error codes easier. If you see an error code is an incredibly low number, you can use a tool like my ValueConverter (http://zathras.de/angelweb/macapplications.htm#ValueConverter), though, to view it as a four char code and then search for that. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
