2015-06-24 2 views
0

У меня была эта проблема со мной вчера. Я имел дело с частью производственного кода, который был сбой в определенный момент с этой аварией ИнформациейОпционально неожиданно найдена информация о ноль и авариях

0 Goga 0x00000001000b90b8 function signature specialization <Arg[0] = Owned To Guaranteed, Arg[1] = Owned To Guaranteed> of Goga.NewViewController.emailButtonPressed (Goga.NewViewController)(ObjectiveC.UIButton) ->() (NewViewController.swift:0) 
1 Goga 0x00000001000c0488 Goga.NewViewController.(emailButtonPressed (Goga.NewViewController) -> (ObjectiveC.UIButton) ->()).(closure #2) (NewViewController.swift:872) 
2 Goga 0x00000001000bd250 partial apply forwarder for reabstraction thunk helper from @callee_owned (@in ObjectiveC.UIAlertAction!) -> (@out()) to @callee_owned (@owned ObjectiveC.UIAlertAction!) -> (@unowned()) (NewViewController.swift:0) 

Однако, когда я нашел ошибку, после нескольких часов, пытаясь повторить вопрос, либо сообщение об ошибке для него не могло в журнале сбоев. Ошибка показывала в XCode вместо как:

неожиданно нашел ноль в то время как разворачивание необязательного значения

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

Edit:

Просто, чтобы добавить немного больше точки зрения исходной задачи, я нашел этот вопрос в этом примере кода:

let cell = tableView.cellForRowAtIndexPath(indexPath) 
cell.textLabel.text = "Hello" // CRASH if the cell is not visible in the view 

Я должен был сделать это вместо:

if let cell = tableView.cellForRowAtIndexPath(indexPath) { 
    cell.textLabel.text = "Hello" // Never get executed if cell is nil 
} 
+1

поделиться своим кодом –

+1

@JayGajjar Вопрос не ищет конкретного решения, а скорее как «поймать» ошибку. – nhgrif

+0

Отлаживайте свой код и найдите на самом деле, на какой строке ваш код разбился! Возможно, вы забыли инициализировать любую вашу переменную. –

ответ

0

При использовании опций вы должны условно разворачивать их с помощью оператора if.

var yourOptional: String? 

if let unwrapped = yourOptional { 
// Do something with the variable 
} else { 
// It was nil 
} 
+0

Я полностью вас поймаю, но ошибки происходят, и если значение, скажем так, возвращается вызовом функции, который в каком-то редком случае возвращает нуль, было бы не слишком очевидно обращаться с ним таким образом. –

+0

Обязанности разработчика - обрабатывать ошибки? Если не разработчик, кто, пользователь? То, что нелегко обрабатывать ошибки, не имеет значения, это часть работы. Если вы явно разворачиваете «!» когда ниль можно каким-либо образом вернуть, не так, это так просто. – zaph

+0

@zaph Я согласен с тобой. Но иногда наш мозг разбрасывается :) –

5

Путь к «улавливанию» ошибки «nil-optional» заключается в простом написании кода. Не злоупотребляйте принудительной разворачиваемостью и принудительным литьем.

В данном конкретном случае, просто читая подробности аварии может дать нам некоторую информацию:

1 Goga 0x00000001000c0488 Goga.NewViewController.(emailButtonPressed (Goga.NewViewController) -> (ObjectiveC.UIButton) ->()).(closure #2) (NewViewController.swift:872) 

Где-то около линии 872 из NewViewController.swift, вы сила разворачивает то, что это на самом деле nil (и, следовательно, не может быть развернуто) ,

Решение состоит в том, чтобы перейти к строке 872 из NewViewController.swift, найти любые вхождения восклицательного знака, определить, является ли это оператором принудительной развязки или булевым оператором ... и если это оператор развертывания силы, исправьте его используя необязательные шаблоны привязки Swift.

Это может быть, что вы делаете что-то вроде этого:

let foo = bar! 

или, возможно, где-то bar объявлен как это:

var bar: AnyObject! 

Тогда он никогда не инициализирован (или в какой-то момент установлен в nil), а затем, поскольку он неявно развернут, вы делаете что-то вроде этого:

let foo: AnyObject = bar 

Они могут привести к ошибке, на которую вы смотрите.

Да, неявно развернутые опции и принудительная разворачивание могут сделать вещи немного более удобными при написании кода, но в конце концов все это означает, что вы сталкиваетесь с этими проблемами, которые вы должны в конечном итоге отследить позже.И нет необходимости делать это, когда у Swift есть много инструментов, чтобы мы были в безопасности с nil.

+0

Собственно, это то, что я сделал. На этой линии не было ничего плохого. Когда я прокомментировал строку (это было не важно в любом случае), то такая же ошибка начала происходить в более позднем месте в той же функции, которая содержит строку. Вы можете подумать, у меня такая же проблема в этом другом месте; тем не менее, я заверяю вас, что я тщательно обрабатывал это дело для любых нулевых значений. –

+0

Вместо того, чтобы смотреть выше/ниже этой * строки * кода, вам нужно посмотреть выше/ниже этого вызова в стеке. Либо что-то посылает потенциально «nil» значение до 872, либо 872 отправляет потенциально «нулевое» значение вниз во что-то другое, которое либо неправильно разрешает «nil», либо неправильно обрабатывает «nil». Если вы можете воссоздать этот сбой, вы всегда можете найти точки останова или вызовы 'println()' для отслеживания кода до источника ошибки. – nhgrif

+0

Я согласен с тобой. Береженого Бог бережет –

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