2015-05-15 2 views
2

Это мой код для совершения сетевого звонка forecast.io. Внутри ViewController у меня есть:Сбой сетевого соединения из-за разворачивания

private let apiKey = ""//my key 

override func viewDidLoad() { 
    super.viewDidLoad() 
    // Do any additional setup after loading the view, typically from a nib. 
    let baseURL = NSURL(string: "https://api.forecast.io/forecast/\(apiKey)") 
    let forecastURL = NSURL(string: "37.8267,-122.423", relativeToURL : baseURL) 

    let sharedSession = NSURLSession.sharedSession() 
    let downloadTask : NSURLSessionDownloadTask = sharedSession.downloadTaskWithURL(forecastURL!, completionHandler: { (location: NSURL!, response: NSURLResponse!, error: NSError!) -> Void in 
     if (error == nil) { 
      let dataObject = NSData(contentsOfURL: location) 
      let weatherDictionary : NSDictionary = NSJSONSerialization.JSONObjectWithData(
       dataObject!, options: nil, error: nil) as! NSDictionary 
     } 
    }) 
    downloadTask.resume() 
} 

Я пытаюсь установить свои данные в NSDictionary, чтобы иметь возможность доступа к нему. У меня есть ошибка (зеленая линия), которая имеет что-то делать с weatherDictionary:

fatal error: unexpectedly found nil while unwrapping an Optional value

Я разворачивания dataObject, так что может быть проблема?

+0

weatherDictionary должен иметь значение nil. Проверьте данныеОбъект – Ritu

+0

Вы подтвердили, что действительный JSON возвращается? И что JSON действительно представляет собой * словарь *? - Btw ([Я повторяюсь] (http://stackoverflow.com/questions/30219596/unable-to-make-network-call#comment48544525_30219596)): Используйте параметр ошибки !! –

+0

комментируя weatherdictionary и println (dataObject), говорит мне, что это не JSON. Но разве погодаDictionary не должна делать это JSON? Если это не проблема, поскольку dataObject - это просто строка чисел. – ecoguy

ответ

3

Вы действительно, серьезно, должны избавиться от привычки вскрытия силы. Если всякий раз, когда вы получаете опцион, вы просто используете !, чтобы развернуть его, вы будете навсегда нападать на эти проблемы.

Вот версия вашего внутреннего кода, который проверяет УСТРОЙСТВА на каждом шагу:

let sharedSession = NSURLSession.sharedSession() 
let downloadTask = sharedSession.downloadTaskWithURL(forecastURL!) 
{ location, response, error in 

    if let error = error { 
     // log error 
    } 
    else if let dataObject = NSData(contentsOfURL: location) { 

     let weatherObj: AnyObject? = NSJSONSerialization.JSONObjectWithData(
      dataObject, options: nil, error: nil) 

     if let weatherDictionary = weatherObj as? NSDictionary { 

     } 
     else { 
      // log error with conversion of weather to dictionary 
     } 

    } 
    else { 
     // log error with dataObject 
    } 
} 

Да, это больше и больше раздражает писать (хотя, умозаключение типа поможет идти в другую сторону - вы не 't должны явно вводить все, например, в обратном вызове, более ясное IMO, чтобы оставить типы выключенными).

Да, иногда вы точно знаете, что значение не будет равно нулю, поэтому проще и проще просто развернуть его (например, с помощью вашего NSURL - вы можете быть довольно безопасным с этим, -вход).

Но до тех пор, пока вы не дойдете до такой степени, что не будете постоянно ловить голову против ошибок, связанных с нулевой стоимостью, лучше написать свой код таким образом.

После того, как вам станет удобнее обращаться с опциями, explore the other techniques, чтобы написать код neater.

Вы могли бы также рассмотреть возможность использования более сильную типизации при обработке результатов JSON, например, вы можете сделать следующее:

if let weatherDictionary = weatherObj as? [String:AnyObject] 

и так далее при обработке внутренней части словаря. Опять же, если вы доверяете forecast.io, чтобы всегда предоставлять вам достоверные данные JSON в правильной форме, вы можете пропустить этот шаг и принудительно выполнить все, но это будет сложнее отлаживать при написании кода, и вы рискуете, чтобы ваш код взорвался на производстве (как напротив, неудачно изящно), если вы когда-нибудь получите поврежденные данные.

Смежные вопросы