Nell'esempio di funzione, (leggi | scrivi) DocumentsFromFile (...) avere alcuni wrapper di funzioni sembra certamente logico poiché tutto in OSx e iOS sembra aver bisogno di tre o quattro classi principali istanziate e un mucchio di proprietà, configurate, collegate, istanziato e impostato, solo per scrivere "Ciao" in un file, in 182 paesi.
Tuttavia, questi esempi non sono abbastanza completi da utilizzare in un vero programma. La funzione di scrittura non segnala alcun errore durante la creazione o la scrittura nel file. Sulla lettura, non penso sia una buona idea restituire un errore che il file non esiste come stringa che dovrebbe contenere i dati letti. Vorresti sapere che non è riuscito e perché, attraverso un meccanismo di notifica, come un'eccezione. Quindi, è possibile scrivere un codice che emetta qual è il problema e consente all'utente di risolverlo, oppure "correttamente" interrompe il programma in quel punto.
Non si vorrebbe semplicemente restituire una stringa con un "File di errore non esiste" in essa. Quindi, dovresti cercare l'errore nella stringa dalla funzione di chiamata ogni volta e gestirlo lì. Probabilmente non puoi davvero dire se la stringa di errore è stata effettivamente letta da un file reale o se è stata prodotta dal tuo codice.
Non puoi nemmeno chiamare la lettura in questo modo in swift 2.2 e Xcode 7.3 perché NSString (contentsOfFile ...) genera un'eccezione. È un errore di compilazione se non si dispone di codice per catturarlo e fare qualcosa con esso, come stamparlo su stdout o, meglio, una finestra popup di errore o stderr. Ho sentito che Apple si sta allontanando dal tentativo di cattura ed eccezioni, ma sarà una lunga mossa e non è possibile scrivere codice senza questo. Non so da dove provenga l'argomento & error, forse una versione precedente, ma NSString.writeTo [File | URL] al momento non ha un argomento NSError. Sono definiti in questo modo in NSString.h:
public func writeToURL(url: NSURL, atomically useAuxiliaryFile: Bool, encoding enc: UInt) throws
public func writeToFile(path: String, atomically useAuxiliaryFile: Bool, encoding enc: UInt) throws
public convenience init(contentsOfURL url: NSURL, encoding enc: UInt) throws
public convenience init(contentsOfFile path: String, encoding enc: UInt) throws
Inoltre, il file inesistente è solo uno dei numerosi problemi che il tuo programma potrebbe avere leggendo un file, come un problema di autorizzazioni, la dimensione del file o numerosi altri problemi per i quali non vorresti nemmeno provare a codificare un gestore ognuno di loro. È meglio supporre che sia tutto corretto e catturare e stampare, o gestire, un'eccezione se qualcosa va storto, inoltre, a questo punto, non hai davvero scelta comunque.
Ecco le mie riscritture:
func writeToDocumentsFile(fileName:String,value:String) {
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0] as NSString!
let path = documentsPath.stringByAppendingPathComponent(fileName)
do {
try value.writeToFile(path, atomically: true, encoding: NSUTF8StringEncoding)
} catch let error as NSError {
print("ERROR : writing to file \(path) : \(error.localizedDescription)")
}
}
func readFromDocumentsFile(fileName:String) -> String {
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0] as NSString
let path = documentsPath.stringByAppendingPathComponent(fileName)
var readText : String = ""
do {
try readText = NSString(contentsOfFile: path, encoding: NSUTF8StringEncoding) as String
}
catch let error as NSError {
print("ERROR : reading from file \(fileName) : \(error.localizedDescription)")
}
return readText
}