Лучший способ обработать и сообщить об ошибках распределения памяти из-за целочисленного переполнения в Objective C?

Что касается динамически растущего хранилища на основе массивов, здесь можно сделать очень много. Я разработчик планировщика Moab для суперкомпьютеров, и мы также имеем дело с очень большим количеством систем с тысячами процессоров, тысячами заданий и огромными объемами вывода заданий. В какой-то момент вы не можете объявить буфер больше, не создавая совершенно новый тип данных для работы с размерами, превышающими UINT_MAX или LONG_LONG_MAX и т. Д., И в этот момент на большинстве «обычных» машин вы будете в любом случае не хватает места в стеке / куче. Поэтому я бы сказал, что записывать значимое сообщение об ошибке, не допускать взрыва коллекции, и если пользователю нужно добавить столько вещей в коллекцию CHDataStructures, они должны знать, что есть проблемы, связанные с очень большими числами, и вызывающий следует проверить, было ли добавление успешным (отслеживать размер коллекции и т. д.).

Другой возможностью является преобразование хранилища на основе массива в хранилище на основе динамически выделяемого связанного списка, когда вы доходите до точки, когда вы не можете выделить больший массив с unsigned int или unsigned long. Это было бы дорого, но происходило бы достаточно редко, чтобы не было ужасно заметно для пользователей фреймворка.Поскольку ограничение на размер динамически выделяемой коллекции на основе связанного списка - это размер кучи, у любого пользователя, добавившего достаточно элементов в коллекцию для «переполнения», возникнут более серьезные проблемы, чем то, был ли его элемент успешно добавлен.

Я бы сказал, что правильнее всего было бы делать то, что делают коллекции Какао. Например, если у меня есть следующий код:

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    NSMutableArray * a = [[NSMutableArray alloc] init];

    for (uint32_t i = 0; i < ULONG_MAX; ++i) {
        for (uint32_t i = 0; i < 10000000; ++i) {
            [a addObject:@"foo"];
        }
        NSLog(@"%lu rounds of 10,000,000 completed", i+1);
    }

    [a release];

    [pool drain];
    return 0;
}

.. и я просто позволю ему работать, он в конечном итоге умрет с EXC_BAD_ACCESS. (Я скомпилировал и запустил это как 32-битное приложение, чтобы быть уверенным, что у меня закончится место, когда я попаду на 2 ** 32 объекта.

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

Регистрировать и вызывать исключение.

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

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

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

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

Документация очень краткая: Утверждения и ведение журнала .