Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line in swizzledDealloc triggers exception breakpoints #11

Open
dredenba opened this issue Apr 28, 2015 · 8 comments
Open

Line in swizzledDealloc triggers exception breakpoints #11

dredenba opened this issue Apr 28, 2015 · 8 comments

Comments

@dredenba
Copy link

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
)
@devxoul
Copy link
Owner

devxoul commented Apr 28, 2015

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.

@tobihagemann
Copy link

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

@devxoul
Copy link
Owner

devxoul commented Jun 5, 2015

😄

@devxoul
Copy link
Owner

devxoul commented Jun 8, 2015

How about this approach? #12

@max0ne
Copy link

max0ne commented Aug 23, 2016

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

@devxoul
Copy link
Owner

devxoul commented Aug 23, 2016

@maxone, that's good approach. By the way, couldn't #12 solve this issue?

@dourgulf
Copy link

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.

@dourgulf
Copy link

And lucky, it also help to solve #12 , because the addObserver and removeObserver is in the same life cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants