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 <michael.peternell@gmx.at> 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 <swift-evolution@swift.org>:
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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:
On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution