2016-03-21 6 views
1

Gemäß der Klassenreferenz akzeptiert der Beendigungshandler für captureStillImageAsynchronouslyFromConnection ein NSError-Objekt, ist jedoch nicht optional.Konflikt zwischen Funktionsdeklaration und Parameterbeschreibung für captureStillImageAsynchronouslyFromConnection?

Funktion Deklaration:

func captureStillImageAsynchronouslyFromConnection(connection: AVCaptureConnection!, completionHandler handler: ((CMSampleBuffer!, NSError!) -> Void)!) 

Doch in der Beschreibung für die Parameter, heißt es null in den Abschluss-Handler anstelle des NSError Objekts zurückgegeben werden, wenn die Anforderung erfüllt wurde.

Parameter Beschreibung:

If the request could not be completed, an NSError object that describes the problem; otherwise nil. 

Die Beschreibung schlägt vor, die Erklärung eine optionale für das NSError Objekt enthalten soll, oder nicht? Sind die Parameter Beschreibung und Funktionsdeklaration nicht widersprüchlich?

Antwort

1

Solange Sie nicht auspacken und ein optionales verwenden, das null ist, geht es Ihnen gut.

Hier ist ein Beispielcode, um die Variationen zu zeigen. Beachten Sie, dass die Callback-Signatur implizite, unverpackte Optionale verwendet, während die übergebenen Parameter null sein können.

import Foundation 

struct Buffer { 
} 

func foo(callback: (buffer: Buffer!, error: NSError!) -> Void) { 
    print("#1: buffer and error are nil") 
    callback(buffer: nil, error: nil) 
    print("#2: buffer not nil, error is nil") 
    callback(buffer: Buffer(), error: nil) 
    print("#3: buffer is nil, error is not nil") 
    callback(buffer: nil, error: NSError(domain: "domain", code: 123, userInfo: nil)) 
    print("#4: both buffer and error are not nil") 
    callback(buffer: Buffer(), error: NSError(domain: "domain", code: 123, userInfo: nil)) 
} 

func cb(buffer: Buffer!, error: NSError!) { 
    if let buffer = buffer { 
     print(buffer) 
    } 
    else { 
     print("buffer is nil") 
    } 

    if let error = error { 
     print(error) 
    } 
    else { 
     print("error is nil") 
    } 
} 

foo(cb) 

Wie aus diesem Beispiel ersichtlich, kann ein implizites, nicht aufgewickeltes optionales Nil sein. Das ist, was die Beschreibung für NSError angibt.

+0

so ist der Grund für die Verwendung einer impliziten Option in der Deklaration, im Gegensatz zu einer normalen optional, dass Sie nicht gezwungen sind zu verwenden! während der Funktion selbst? Vielen Dank! – Crashalot

+0

Das ist ein guter Grund, aber seien Sie vorsichtig, nicht überfällig. Es gibt einige gute Anwendungsfälle, aber Sicherheit gewinnt. Bitte überprüfe @ drewags Beitrag unter diesem Link: http://stackoverflow.com/questions/24006975/why-create-implicitly-unwrapped-optionals um mehr über die vielen Möglichkeiten zu erfahren, wie man es benutzen kann, während man sicher spielt. – Laurent

+0

yup, verstanden. Ich versuche nur zu verstehen, warum Apple ein implizites, nicht gefaltetes, optionales, im Gegensatz zu einem normalen, optionales verwendet. Ist das der Grund? – Crashalot