Práctica recomendada: dominios y códigos NSError para su propio proyecto o aplicación

Question

Existe un previous SO post relacionado con la configuración de dominios de error para sus propios marcos, pero cuál es la mejor práctica para configurar dominios de error y códigos de error personalizados para su propio proyecto/aplicación?

Por ejemplo, supongamos que está trabajando en una aplicación intensiva de Data Core con muchas validaciones, ¿debería seguir con los códigos de error de datos básicos "comunes" (como NSManagedObjectValidationError desde CoreDataErrors.h) o debería crear sus propias MyAppErrors.h y definir los errores con más especificidad (es decir, MyAppValidationErrorInvalidCombinationOfLimbs?

Creación de un dominio de error personalizado y un conjunto de códigos de error podría eliminar la ambigüedad significativamente su código, pero ¿es demasiado trabajo para mantener y tiene uno que preocuparse por error ¿Hay algún otro problema aquí?

Answer 1

Yo personalmente uso un rever dominio de estilo se-DNS. Por ejemplo:

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

La tercera parte del dominio (@"myproject") sólo se utiliza para diferenciar los errores de este proyecto ("My Project") de los errores en otro proyecto ("My Other Project" =>com.davedelong.myotherproject).

Es una forma sencilla de asegurarse de que no voy a entrar en conflicto con los dominios de error de cualquier otra persona (si estoy usando el código de tercera parte), a menos que el desarrollador está tratando a propósito para meterse con simplemente mí (que yo creer sería altamente improbable ...).

En cuanto a los conflictos de numeración de código, no se preocupe por eso. Siempre que los códigos sean únicos dentro de un dominio, debería estar bien.

En cuanto a la traducción de errores, eso depende de usted. Hagas lo que hagas, asegúrate de documentarlo bien. Personalmente, suelo transmitir los errores generados por el framework a medida que me llegan, ya que nunca estoy seguro de poder manejar todos los códigos y traducir todo el userInfo en algo más específico para mi proyecto. Los marcos podrían cambiar y agregar más códigos, o cambiar el significado de los códigos existentes, etc. También me ayuda a identificar más específicamente de dónde vino el error. Por ejemplo, si mi marco StackKit genera un error en el dominio com.stackkit, sé que es un problema de infraestructura. Sin embargo, si genera un error en el NSURLErrorDomain, entonces sé que proviene específicamente del mecanismo de carga de URL.

Lo que podía hacer es capturar el error marco generado y lo envuelve en un nuevo objeto de error que tiene su dominio y un código genérico, algo así como kFrameworkErrorCodeUnknown o algo, y luego coloque el error capturado en el userInfo bajo la NSUnderlyingErrorKey. CoreData hace esto mucho (por ejemplo, si intenta save: un NSManagedObjectContext, pero tiene errores de integridad de relación, obtendrá un solo error, pero el NSUnderlyingErrorKey contendrá mucha más información, como específicamente qué relaciones son incorrectas, etc.)

Answer 2

No tengo suficiente representante para comentar, pero para la respuesta aceptada por Dave DeLong, podría ser un poco mejor usar [[NSBundle mainBundle] bundleIdentifier] en lugar de @"com.myName.myProject". De esta manera, si cambias el nombre o el nombre de tu proyecto, se reflejará con precisión.