NSAssert rzuci wyjątek, gdy nie powiedzie się. NSAssert ma więc istnieć krótki i łatwy sposób pisania i sprawdzania wszelkich założeń, które poczyniłeś w swoim kodzie. To nie jest (moim zdaniem) alternatywa dla wyjątków, tylko skrót. Jeśli asercja się nie powiedzie, oznacza to, że coś poszło nie tak w twoim kodzie i program nie powinien kontynuować.
Należy zwrócić uwagę na to, że NSAssert nie zostanie wkompilowany do twojego kodu w kompilacji wydania, więc jest to zwykle używane do sprawdzania poprawności podczas programowania. Właściwie używam niestandardowego makra assert, które jest zawsze aktywne.
Czasy, w których chciałbyś @throwswój własny NSException, są wtedy, gdy zdecydowanie chcesz go w kompilacji wydania oraz w rzeczach, takich jak biblioteki publiczne / interfejs, gdy niektóre argumenty są nieprawidłowe lub zostałeś nieprawidłowo wywołany. Zauważ, że @catchwyjątek nie jest standardową praktyką i kontynuuj uruchamianie aplikacji. Jeśli spróbujesz tego z niektórymi standardowymi bibliotekami Apple (na przykład Core Data), mogą się zdarzyć złe rzeczy. Podobnie jak w przypadku potwierdzenia, jeśli zostanie zgłoszony wyjątek, aplikacja powinna zasadniczo zakończyć się dość szybko, ponieważ oznacza to, że gdzieś wystąpił błąd programowania.
NSErrors powinny być używane w twoich bibliotekach / interfejsach dla błędów, które nie są błędami programowania i które można odzyskać. Możesz podać informacje / kody błędów wywołującemu, który może obsłużyć błąd, w razie potrzeby powiadomić użytkownika i kontynuować wykonywanie. Zwykle dotyczy to takich rzeczy, jak błąd nieznalezienia pliku lub inny błąd niekrytyczny.