Найкраща практика - домени та коди NSError для власного проекту / програми

Існує попередня публікація про те, що стосується налаштування доменів помилок для власних фреймворків, але яка найкраща практика щодо налаштування доменів помилок та спеціальних кодів помилок для вашого власного проекту / програми ?

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

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

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

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

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

Це простий спосіб , щоб переконатися , що я не збираюся конфліктує з доменами помилок хто - небудь інший (якщо я використовую 3 - ї код партії), якщо що розробник цілеспрямовано намагається забруднити тільки мені (який я вважаю , було б дуже малоймовірно. ..).

Що стосується конфліктів з нумерацією коду, не хвилюйтеся з цього приводу. Тільки доки коди є унікальними в домені , ви повинні бути в порядку.

Що стосується перекладу помилок, то це залежить від вас. Що б ви не робили, переконайтесь, що це добре документується. Особисто я просто передаю помилки, створені рамками, коли вони потрапляли до мене, оскільки я ніколи не впевнений, що я оброблю всі коди та перекладу всі користувальницькі дані в щось більш конкретне для мого проекту. Рамки можуть змінювати та додавати більше кодів, або змінювати значення існуючих кодів тощо. Це також допомагає мені більш точно визначити, звідки виникла помилка. Наприклад, якщо мій фреймворк StackKit генерує помилку в com.stackkitдомені, я знаю, що це рамкова проблема. Однак, якщо він генерує помилку в NSURLErrorDomain, то я знаю, що це спеціально походить від механізму завантаження URL-адрес.

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

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

Як створити користувацький 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 і закінчите.