Блог

Полное сообщение об ошибке:

 error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

error: <EXPR>:19:5: error: use of unresolved identifier '$__lldb_injected_self'
    $__lldb_injected_self.$__lldb_wrapped_expr_7(
    ^~~~~~~~~~~~~~~~~~~~~
 

Эта ошибка появляется в консоли, когда я запрашиваю значение Dictionary<String, String> свойства в универсальном UITableViewController (TVC).

Подробнее…

У меня есть общий TVC (указанный выше), который более или менее основан на структуре, изложенной в книге Флориана Куглера и Даниэля Эггерта «Основные данные», и принимает, среди прочего, общее значение T.

 class TVCDataSource_List<T: Managed, etc...>
 

Этот общий TVC включает в себя словарь, предназначенный для хранения списка более длинных «альтернативных» имен для заголовков разделов TVC.

 var dictionarySectionData: [String: String] = [:]
 

Я решил запрограммировать TVC таким образом, потому что кажется более эффективным хранить ссылку на имя в виде коротких двух символов String в атрибуте модели данных (идентификатор раздела), чем длинное имя в виде String .

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

• Я просматриваю код с помощью отладчика, и, как и ожидалось, словарь заполняется с помощью одного запроса на выборку в постоянное хранилище;
• Сразу после вызова print(dictionarySectionData.description) консоли выводится правильно заполненный словарь, как и ожидалось;
• Запрос LLDB с p dictionarySectionData помощью (или po ) непосредственно перед и после этого print на консоль выдает полное сообщение об ошибке, подробно описанное в начале этого вопроса;
• В то же время средство просмотра переменных помощника редактора показывает, что словарь пуст, что неожиданно противоречит печати;
• Я продолжаю пошагово выполнять код для построения TVC, поскольку в словаре больше нет пар ключ-значение, я не могу вспомнить значение для заголовка моего раздела, и, как и ожидалось, консоль сообщает «Фатальная ошибка: неожиданно найдено значение nil при развертывании необязательного значения».

Я провел небольшое простое исследование:

1. Этот блог Скотта Берревоца озаглавлен «Повторная привязка self: точка прерывания (редактирования) отладчика».
2. Это сообщение об ошибке Swift от Кита Смайли под названием «LLDB: предупреждение: инициализация переменной’$ __lldb_error_result'».
3. Это сообщение об ошибке Swift от Зева Айзенберга под названием «ошибка: использование необъявленного типа’$__lldb_context’ в расширении NSAttributedString».

Кажется, у меня может быть либо:

• наткнулся на ошибку в компиляторе; или
• попытка установить значение для словаря в универсальном TVC таким образом, чтобы компилятор интерпретировал попытку повторной привязки к self??

Frankly neither of which I understand and from my shallow knowledge of the compiler and Swift, would take me months, possibly years of learning and experience. Which I’m happy to slowly accumulate over time.

I do have a satisfactory solution… instead of building a dictionary of the longer ‘alternative’ names for the TVC’s section headers at the beginning of the TVC lifecycle, I run a fetch request EACH TIME the code resolves the name for the current TVC section header. This works perfectly and does not block the UI (yet).

However, it really annoys me that I cannot run one fetch at the start of the construction of my generic TVC to prepare a concise dictionary of longer ‘alternative’ names for the TVC’s section headers and instead have to run a fetch for each section that the user decides to scroll through. To perform one fetch and hold a dictionary of 12-15 key value pairs in memory seems far more efficient that running many fetches.

Has any one experienced this problem?

If so, are you able to offer any advice?

UPDATE

The problem seems to be with my use — or perhaps more correctly, my misuse — of the explicitly unwrapped Optional .

Here is the code I use to populate the dictionary…

 func createDictionaryOfSectionHeaderText() {

    let request = Types.preparedFetchRequest
    // noting .preparedFetchRequest is a static var, available through generics

    let key = "typeParent.typeParentName"
    let name = "Taxonomy"
    let predicate = NSPredicate(format: "%K == %@", argumentArray: [key, name])

    request.predicate = predicate

    var results: [Types] = []

    do {

        results = try <<My NSManagedObjectContext>>.fetch(request)
    }
    catch {

        let fetchError = error
        print(fetchError)
    }

    for type in results {

        let formatSortOrder = String(format: "d", type.sortOrder)
        dictionarySectionData[formatSortOrder] = type.typeName
    }
}
 

Сообщение об ошибке было вызвано двумя элементами кода…

A. Как указано выше в func createDictionaryOfSectionHeaderText()

 let stringSortOrder = String(type.sortOrder)
let formatSortOrder = String(format: "d", stringSortOrder)
 

… которая передавала строку в формат «% 02d», не зная эффекта… TBA.

(Теперь эти две строки заменены на единственную let formatSortOrder = String(format: "d", type.sortOrder) — что, конечно, работает.)

B. В UITableViewDelegate методе func tableView(_ tableView: UITableView, viewForHeaderInSection section: Int) -> UIView?

 stringHeaderText = dictionarySectionData[stringSectionName]!
// "Fatal error: Unexpectedly found nil while unwrapping an Optional value"
 

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

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

 stringHeaderText = dictionarySectionData[stringSectionName] ?? "ERROR"
 

Я могу даже дать ответ, если / когда я пойму это лучше.

Эти проблемы должны быть решены в XCode 12. В XCode 10 и 11 действительно было много ошибок, особенно когда дело касалось дженериков