Best Practice - Домены и коды NSError для вашего собственного проекта/приложения

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

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

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

Ответ 1

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

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

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

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

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

Что касается перевода ошибок, то вам. Независимо от того, что вы делаете, убедитесь, что вы хорошо документируете его. Лично я обычно просто передаю фреймворк-ошибки, поскольку они пришли ко мне, так как я никогда не уверен, что буду обрабатывать все коды и переводить всю пользовательскую информацию в нечто более специфичное для моего проекта. Структуры могут изменять и добавлять больше кодов или изменять смысл существующих кодов и т.д. Это также помогает мне более конкретно определить, откуда возникла ошибка. Например, если моя инфраструктура StackKit генерирует ошибку в домене com.stackkit, я знаю, что это проблема структуры. Однако, если он генерирует ошибку в NSURLErrorDomain, то я знаю, что она специально появилась из механизма загрузки URL.

Что вы можете сделать, так это захватить созданную фреймворком ошибку и обернуть ее в новый объект ошибки, в котором есть ваш домен и общий код, что-то вроде kFrameworkErrorCodeUnknown или что-то еще, а затем поместить захваченную ошибку в userInfo в NSUnderlyingErrorKey. CoreData делает это много (например, если вы пытаетесь save: a NSManagedObjectContext, но у вас есть ошибки целостности отношений, вы получите одну ошибку, но NSUnderlyingErrorKey будет содержать гораздо больше информации, например, какие отношения неправильны и т.д.).

Ответ 2

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