I don't have experience with AVFoundation, but looking at some docs, it's still throwing NSError, just the error codes are defined there. And NSError is the Cocoa error class.
The same way NSString may be subclassed in your own app, and you can pass it to String(cocoaString:) while it's no longer technically Cocoa. The Cocoa term is IMHO vague enough and often used to express any coding in ObjC. String(cocoaString:) probably isn't the most precise naming either, but the alternatives are worse: - String(objectiveCString:) - NSString is not bound to ObjC - String(NSString:) - looks a bit weird - String(foundationString:) - probably the most precise but most confusing. > On Jun 29, 2016, at 6:54 PM, Michael Peternell <[email protected]> > wrote: > > Hmm, not all NSErrors are Cocoa Errors. CustomNSError is a perfectly scoped > name: CustomError would be too vague, CustomCocoaError excludes errors thrown > by AVFoundation. And the intent is perfectly clear without explanation. I > think a CustomCocoaError would have documentation comment that says that it > can be used to customize "NSError behavior". After all, a `CustomNSError` is > a custom `NSError`. > > -Michael > >> Am 29.06.2016 um 08:45 schrieb Charlie Monroe via swift-evolution >> <[email protected]>: >> >> Perhaps it could be CustomCocoaError, having the "Cocoa" part precedence in >> >> String(cocoaString: NSString) >> >> >>> On Jun 29, 2016, at 7:31 AM, Riley Testut via swift-evolution >>> <[email protected]> wrote: >>> >>> Love the proposal overall, but not sure about the CustomNSError name >>> either. It doesn’t seem to read like a Swift protocol name. >>> >>> Somewhat related, is there a reason these protocols don’t contain the >>> “Protocol” suffix? Stands in stark contrast with the rest of the Swift >>> protocol naming conventions (AFAIK). >>> >>>> On Jun 28, 2016, at 4:33 PM, Douglas Gregor via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>>> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> Obviously, I’m in favor of this one. +1! >>>>> >>>>> I think I did prefer the older name of CustomUserInfoError for the >>>>> domain/code/userInfo protocol, rather than CustomNSError. This is just >>>>> because I’d like to be able to do a global search through my project for >>>>> “NSError” and have it turn up empty. Maybe a silly reason, I know. ;-) >>>> >>>> >>>> I’m floating CustomNSError as the protocol name because I don’t feel that >>>> domain, core, or userInfo are fundamental to the Swift error model—they’re >>>> about exposing things specifically to NSError. >>>> >>>> - Doug >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
