Introduction

Xcode’s All Exceptions breakpoint is useful because it stops at the moment an exception is thrown, even before a crash becomes visible. The downside is that frameworks sometimes throw and handle exceptions internally, so a broad exception breakpoint can become noisy unless you narrow it with conditions, module scope, or actions.

Understand Why the Breakpoint Feels Noisy

An exception breakpoint does not know whether an exception is fatal, temporary, or already handled. It simply sees that an exception was thrown and stops execution.

That means you may break inside framework code paths that never turn into user-visible failures. The real debugging question is not only “was an exception thrown,” but “is this exception relevant to the bug I am investigating?”

Start with a More Targeted Breakpoint If Possible

Before building ignore rules, check whether All Exceptions is even the right tool. In many debugging sessions, a narrower choice gives a better signal:

• an Objective-C exception breakpoint instead of every exception type
• a symbolic breakpoint on objc_exception_throw
• an ordinary file or line breakpoint around the failing feature

A better-scoped breakpoint often removes the need for complicated filtering altogether.

Add a Condition to Skip a Known Benign Exception

If you do want a broad exception breakpoint, Xcode lets you add an LLDB condition. For Objective-C exceptions, that condition can inspect the exception object and choose not to stop for one specific name.

(BOOL)![(NSString *)[(NSException *)$arg1 name] isEqualToString:@"NSAccessibilityException"]

The idea is simple: break unless the exception name matches a case you already understand and intentionally want to ignore.

The safe workflow is:

1. break on the noisy exception once
2. inspect the name and stack trace
3. add a condition for that exact benign case only

Keep the ignore rule as narrow as possible.

Log and Auto-Continue Instead of Stopping

Sometimes you still want visibility, but you do not want execution to halt. In that case, add breakpoint actions and enable automatic continue.

Useful LLDB actions include:

po [(NSException *)$arg1 name]
bt

That setup logs the exception name and stack trace while allowing the app to keep running. It is useful when you are measuring frequency or trying to prove that the exception is harmless.

Scope by Module When the Noise Comes from Frameworks

If the unwanted exceptions consistently originate from system frameworks, module scoping can be safer than ignoring by name alone. The same exception class may be harmless in one framework and a real bug in your own code.

That is why a blanket “ignore every exception with this name” rule is often riskier than a smaller filter tied to the framework or code path you already understand.

Revisit Ignore Rules After Xcode or SDK Changes

An ignore rule that was safe last month is not guaranteed to stay safe after an SDK update. Framework behavior changes, stack traces move, and a previously harmless throw can become a sign of a new issue.

A good maintenance habit is to temporarily disable custom exception filtering after a major Xcode or iOS SDK upgrade and rerun your important flows. That keeps stale debugger assumptions from hiding real regressions.

Keep Team Sharing Controlled

Breakpoint customization is often highly personal. One developer’s useful noise reduction can become another developer’s missing signal. If you share breakpoint configurations across a team, document exactly what is being filtered and why.

The more automatic the suppression becomes, the more carefully it should be justified.

Common Pitfalls

• Ignoring an exception by name without first checking the actual stack trace.
• Using All Exceptions when a more targeted breakpoint would be simpler and safer.
• Applying a broad ignore rule that also hides exceptions thrown from your own code.
• Turning on auto-continue too early and losing visibility into a real bug.
• Keeping old ignore rules after Xcode or SDK upgrades without revalidating them.

Summary

• 'All Exceptions breakpoints are powerful, but often broader than the bug requires.'
• Prefer narrower breakpoints first when possible.
• If you filter, ignore only specific known benign cases.
• Breakpoint actions plus auto-continue can provide visibility without interruption.
• Recheck custom filters after toolchain upgrades so they do not hide new defects.