Line in swizzledDealloc triggers exception breakpoints
The exception breakpoint is triggered on the line in the try block, and while it does not crash the app it makes using the app in the debugger a pain because it interferes with my ability to identify other exceptions and test my app.
Is there a way to fix this? or even just special case the exception breakpoint behavior?
- (void)swizzledDealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self];
for (NSString *key in self.class.observingKeys) {
@try {
[self removeObserver:self forKeyPath:key];
}
@catch (NSException *exception) {
// Do nothing
}
}
[self swizzledDealloc];
}
It is especially frustrating because it hits that breakpoint for each of the observing keys which typically are the following:
(lldb) po self.class.observingKeys
<__NSArrayI 0x80a267c0>(
attributedText,
bounds,
font,
frame,
text,
textAlignment,
textContainerInset
)
Check this question (Ignore certain exceptions when using Xcode's All Exceptions breakpoint) from StackOverflow.
Also you can build static library(.a) or dynamic framework(.framework) manually then embed it into your project instead of using source code.
Why would you even swizzle dealloc? It's not because of ARC, is it? You're still encouraged to use dealloc even with ARC, you just don't call [super dealloc].
Edit: Oh god, please ignore this... it's late here, we're in a category. xD Sorry! :D
:smile:
How about this approach? #12
You can add a dummy view as a subview to the UITextView, and do your remove observer when the dummy view receives
- [UIView willMoveToSuperview:] with (self.superview && newSuperview == nil).
See line 196 in SVPullToRefresh.m
@maxOne, that's good approach. By the way, couldn't #12 solve this issue?
I make a pull request try to not swizzle dealloc. It may also help to solve other crash case when I using this project in my dynamic framework.
And lucky, it also help to solve #12 , because the addObserver and removeObserver is in the same life cycle.