Я лично использую домен в стиле обратного 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
будет содержать гораздо больше информации, например, специальнокакие отношения неправильные и т. д.).