在iOS开发过程中，可能会遇到各种问题，其中一个常见的问题是尝试将相同的视图控制器实例多次推入导航控制器时导致的崩溃。这种情况通常发生在应用程序打开的应用程序数量过多时，用户再次点击同一个按钮，导致代码尝试将相同的视图控制器两次推入导航控制器，这在iOS中是不被支持的。
第一次尝试是通过使用Objective-C的try/catch结构来处理这个崩溃。尽管有人认为在Objective-C中不应该使用try/catch，因为所有可能的错误条件都应该在执行可能产生异常的代码之前进行检查，但在许多情况下这是不可能做到的。毕竟，程序员如何能预测所有可能发生的错误场景呢？如果程序员确实不应该在Objective-C中使用try/catch，那么为什么这种语言还包含这样的结构呢？在案例中，已经在Objective-C中多次成功使用了try/catch，尤其是在非关键的后台代码中，那里只需要隐藏错误，以免用户看到。例如，在一个应用程序中，一个后台任务更新联系人自动完成数据库（从手机的地址簿中检索）时发生的异常可以被忽略，因为同样的任务可以在没有重大影响应用程序功能的情况下再次执行，因为用户仍然可以在没有自动完成的情况下手动输入数字。
继续运行带有try/catch的修改后的代码，猜怎么着，异常仍然导致应用程序崩溃，就好像try/catch结构从未添加过一样。最终唯一有效的做法是检查相同的视图控制器是否已经在导航堆栈中，如果是这样，就不要再推入它：
if (![self.navigationController.topViewController isKindOfClass:[MyViewController class]]) {
[devNavController pushViewController:myVC animated:YES];
}
但是，为什么try/catch在第一次尝试时没有起作用呢？也许上述的NSInvalidArgumentException在Objective-C中的行为就像Java语言中的java.lang.Error一样，也就是说，它只能通过捕获java.lang.Error的等效物来处理，而不能通过捕获NSException来处理，就像在上面的代码中尝试的那样。或者这可能只是iOS的一个bug。不管原因是什么，这只是Objective-C语言中的另一个怪癖，开发者们必须接受。
在iOS开发中，异常处理是一个重要的主题，特别是当涉及到视图控制器和导航控制器时。正确地管理这些组件可以避免应用程序崩溃，提高用户体验。在本文中，探讨了如何处理尝试将相同的视图控制器实例多次推入导航控制器时导致的问题，以及如何通过检查导航堆栈来避免这一问题。
在处理iOS开发中的异常时，需要记住，尽管try/catch结构在某些情况下很有用，但它并不是万能的。在某些情况下，异常可能无法被捕获，这就需要采取其他措施来确保应用程序的稳定性。例如，可以在代码中添加额外的检查，以确保不会尝试将相同的视图控制器实例多次推入导航控制器。