Домены Best Practice - NSError и коды для Вашего собственного проекта/приложения
Существует предыдущее ТАК сообщение относительно установки ошибочных доменов для Ваших собственных платформ, но что лучшая практика расценивает установку ошибочных доменов и пользовательских кодов ошибок для Вашего собственного проекта/приложения?
Например, предположение, Вы работаете над Базовым Информационно емким приложением с большим количеством проверок, должен Вы просто придерживаться с "с полки" Базовые коды ошибок Данных (такой как NSManagedObjectValidationError от CoreDataErrors.h) или если Вы создаете свое собственное MyAppErrors.h и определите ошибки с большей спецификой (т.е. MyAppValidationErrorInvalidCombinationOfLimbs?
Создание пользовательского ошибочного домена и набора кодов ошибок могло значительно снять неоднозначность Вашего кода, но это является слишком много служебным для поддержания, и нужно волноваться о коде ошибки, нумерующем конфликты? Или есть ли здесь другие проблемы?
1 ответ
Лично я использую домен в стиле reverse-DNS. Например:
NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];
Третья часть домена (@"myproject") используется только для того, чтобы отличить ошибки этого проекта ("My Project") от ошибок другого проекта ("My Other Project" => com.davedelong.myotherproject).
Это простой способ гарантировать, что я не буду конфликтовать с чьими-либо доменами ошибок (если я использую код сторонних разработчиков), если только этот разработчик специально не пытается испортить только меня (что, на мой взгляд, крайне маловероятно...).
Что касается конфликтов нумерации кодов, не беспокойтесь об этом. Если коды уникальны в пределах домена, то все будет в порядке.
Что касается ошибок перевода, это зависит от вас. Что бы вы ни делали, убедитесь, что вы хорошо задокументировали это. Лично я обычно просто передаю ошибки, генерируемые фреймворком, по мере их появления, поскольку я никогда не уверен, что справлюсь со всеми кодами и переведу все userInfo во что-то более специфичное для моего проекта. Фреймворки могут измениться и добавить больше кодов, или изменить смысл существующих кодов и т.д. Это также помогает мне более точно определить, откуда взялась ошибка. Например, если мой StackKit фреймворк генерирует ошибку в домене com.stackkit, я знаю, что это проблема фреймворка. Однако если он генерирует ошибку в домене NSURLErrorDomain, то я знаю, что она возникла именно из-за механизма загрузки URL.
Что вы могли бы сделать, так это перехватить ошибку, сгенерированную фреймворком, и обернуть ее в новый объект ошибки, содержащий ваш домен и общий код, что-то вроде kFrameworkErrorCodeUnknown или что-то в этом роде, а затем поместить перехваченную ошибку в userInfo под NSUnderlyingErrorKey. CoreData делает это часто (например, если вы попытаетесь сохранить: NSManagedObjectContext, но у вас есть ошибки целостности отношений, вы получите одну ошибку, но NSUnderlyingErrorKey будет содержать гораздо больше информации, например, какие именно отношения неверны и т.д.).