Un NSAssert generará una excepción cuando falle. Por lo tanto, NSAssert está ahí para ser una forma corta y fácil de escribir y verificar cualquier suposición que haya hecho en su código. No es (en mi opinión) una alternativa a las excepciones, solo un atajo. Si una afirmación falla, algo ha ido terriblemente mal en su código y el programa no debería continuar.
Una cosa a tener en cuenta es que NSAssert no se compilará en su código en una versión de lanzamiento, por lo que generalmente se usa para verificar la cordura durante el desarrollo. De hecho, tiendo a usar una macro de aserción personalizada que siempre está activa.
Las veces en que usaría @throwsu propia NSException es cuando definitivamente la desea en una versión de lanzamiento, y en cosas como bibliotecas públicas / interfaz cuando algunos argumentos no son válidos o se le ha llamado incorrectamente. Tenga en cuenta que no es una práctica estándar hacer @catchuna excepción y continuar ejecutando su aplicación. Si intenta esto con algunas de las bibliotecas estándar de Apple (por ejemplo, Core Data), pueden suceder cosas malas. De manera similar a una afirmación, si se lanza una excepción, la aplicación generalmente debería terminar con bastante rapidez porque significa que hay un error de programación en alguna parte.
NSErrors debe usarse en sus bibliotecas / interfaces para errores que no son errores de programación y de los que se pueden recuperar. Puede proporcionar información / códigos de error a la persona que llama y ellos pueden manejar el error limpiamente, alertar al usuario si corresponde y continuar con la ejecución. Por lo general, esto sería para cosas como un error de archivo no encontrado o algún otro error no fatal.