Лучшая практика - домены и коды NSError для вашего собственного проекта / приложения - PullRequest
107 голосов
/ 18 июля 2010

Существует предыдущий пост SO , касающийся настройки доменов ошибок для ваших собственных платформ, но каков наилучший способ настройки доменов ошибок и пользовательских кодов ошибок для вашего собственного проекта / приложения * * 1005

Например, предположим, что вы работаете с приложением, интенсивно использующим ядро, с большим количеством проверок, если вы просто придерживаетесь готовых кодов ошибок Core Data (таких как NSManagedObjectValidationError из CoreDataErrors.h) или следует ли вам создать свой собственный MyAppErrors.h и определить ошибки с большей спецификой (например, MyAppValidationErrorInvalidCombinationOfLimbs?

Создание настраиваемого домена ошибок и набора кодов ошибок может значительно устранить неоднозначность вашего кода, но не слишком ли это сложно для обслуживания и нужно ли беспокоиться о конфликтах нумерации кодов ошибок? Или здесь есть другие проблемы?

Ответы [ 3 ]

147 голосов
/ 18 июля 2010

Я лично использую домен в стиле обратного DNS.Например:

NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];

Третья часть домена (@"myproject") используется только для того, чтобы отличить ошибки этого проекта ("My Project") от ошибок в другом проекте ("My Other Project" => com.davedelong.myotherproject).

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

Что касается конфликтов нумерации кода, не беспокойтесь об этом.Пока коды уникальны в домене , вы должны быть в порядке.

Что касается перевода ошибок, это ваше дело.Что бы вы ни делали, убедитесь, что вы хорошо это задокументировали. Лично , я обычно просто передаю сгенерированные фреймворком ошибки, когда они приходят ко мне, так как я никогда не уверен, что обработаю все коды и переведу весь userInfo в нечто более специфичное для моегопроект.Фреймворки могут изменить и добавить больше кодов или изменить значение существующих кодов и т. Д. Это также помогает мне более точно определить, откуда возникла ошибка.Например, если мой StackKit framework генерирует ошибку в домене com.stackkit, я знаю, что это проблема каркаса.Тем не менее, если он генерирует ошибку в NSURLErrorDomain, то я знаю, что это определенно произошло из механизма загрузки URL.это в новом объекте ошибки, который имеет ваш домен и общий код, что-то вроде kFrameworkErrorCodeUnknown или что-то подобное, а затем поместите захваченную ошибку в userInfo под NSUnderlyingErrorKey.CoreData делает это много (например, если вы попытаетесь save: NSManagedObjectContext, но у вас есть ошибки целостности отношений, вы получите одну ошибку обратно, но NSUnderlyingErrorKey будет содержать гораздо больше информации, например, специальнокакие отношения неправильные и т. д.).

35 голосов
/ 29 августа 2014

Мне не хватает представителя, чтобы комментировать, но для принятого ответа Дэйва Делонга, возможно, было бы немного лучше использовать [[NSBundle mainBundle] bundleIdentifier] вместо @"com.myName.myProject".Таким образом, если вы измените свое имя или название проекта, оно будет отражено точно.

4 голосов
/ 24 апреля 2018

Как создать собственный NSError:

Сначала создайте словарь сообщения об ошибке

NSDictionary *userInfo = @{   
   NSLocalizedDescriptionKey: NSLocalizedString(@"Unknown Error - Please try again", nil),
   NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"Unknown Error - Please try again", nil),
   NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Unknown Error - Please try again", nil)
                                               };
NSError *error = [NSError errorWithDomain:[[NSBundle mainBundle] bundleIdentifier] 
  code:-58 userInfo:userInfo];

Затем назначьте userInfo NSDictionary и все готово.

...