Understanding `libc++abi.dylib: terminating with uncaught exception of type NSException (lldb)`

Overview

When developing macOS or iOS applications, encountering exceptions is not uncommon. One particular error message that often puzzles developers is:

• `libc++abi` is the C++ standard library's ABI support for Apple's platforms. It handles low-level operations concerning object creation, exception handling, and type information.
• `dylib` (dynamic library) indicates that this is a shared library used at runtime rather than compiled into the application.
• This part of the message means the application execution was halted because an exception was thrown that did not get handled.
• In Objective-C and Swift, an NSException is an object that represents an exceptional condition, typically indicating invalid operations, failed assertions, or logic errors.
• `NSException` is the base class for all exceptions in Cocoa and Cocoa Touch environments.
• Common `NSException` subtypes include `NSRangeException`, `NSInvalidArgumentException`, and more.
• LLDB stands for the Low-Level Debugger, which is used in Xcode for debugging. The presence of `(lldb)` implies that the program was being executed in a debug mode when the termination occurred.
• Attempting to access an element that is outside the bounds of an array typically raises an `NSRangeException`.
• Passing illegal arguments to methods can result in an `NSInvalidArgumentException`.
• Sending a message to a `nil` object can sometimes lead to undefined behavior or raise an exception if the method is a class method or within some other contexts.
• Sending a message to an object that doesn’t recognize the method (selector) can result in a crash with `unrecognized selector sent to instance`.
• Go to the breakpoint navigator in Xcode.
• Add an exception breakpoint by clicking the `+` button and selecting `Add Exception Breakpoint`.
• Configure it to catch `All Exceptions` or narrow it down to `Objective-C exceptions`.
• When the app crashes, LLDB will pause execution and show the stack trace.
• Review the frames leading up to the crash to determine the source of the exception.
• Use commands like `po` (print-object) or `bt` (backtrace) to inspect objects and their methods.
• Example: `$(lldb) po [array count]$` to print the count of an array causing an issue.
• Always validate inputs and guard against illegal values to pre-empt exceptions.
• Use `@try` and `@catch` blocks (Objective-C) to catch exceptions where they are anticipated.
• In Swift, `do-catch` blocks are used, mainly for handling error objects rather than exceptions.
• Use `defer` to ensure that necessary cleanup is performed before exiting a scope, even when an exception occurs.