NSAssertionHandler
Problem Statement
We see crash logs coming in that have clearly been the result of a failed assertion, but no information is included in the report to aid us in determining which assertion failed or why the assert fell through.
In cases where NSAssertionHandler is involved, additional details may get logged through NSLog but these are not captured by Sentry.
Solution Brainstorm
- Sentry could install a custom
NSAssertionHandler. - Sentry could swizzle the
handleFailuremethods of the assertion handler.
This sounds like a good idea. We need to investigate how much information we can get out of this.
We already have support for support for fatalError, assert, precondition with https://github.com/getsentry/sentry-cocoa/issues/662.
I'd say for me, the primary value of NSAssertHandler is to gracefully document the various potential Apple internal asserts. Although others might use NSAssert themselves in Obj-C code. Typically these are deactivated in production but very useful during development & testing.
@philipphofmann @lhunath I am not totally sure what this issue aims to solve. We already support assert, they get logged in Sentry with the error message and all. Is this for when somebody installs a custom NSAssertionHandler in an Obj-C app? Does that stop our code from handling it?
@lhunath do you have a minimal example repo that shows the problem you want solved?
@lhunath, can you please give us some sample code on how you would expect our SDK to handle your feature request?
@kevinrenskers I apologize, I can't be of huge help – my primary aim was to avoid the issue described in the screenshot; ie. void of any context about the assert that triggered the crash. I do not know why this issue was logged as-is if, as you say, "asserts already get logged in Sentry with the error message and all". This was not my experience. Unfortunately, I can no longer find the issue at hand. I can confirm that my project does /not/ have any custom NSAssertionHandlers installed, nor does it use any libraries that would (Sentry aside). Feel free to close if you feel there is nothing to do here; though note that the screenshot issue was still generated and likely shouldn't have been, according to your claim.
If you could supply sample code that reproduces the problem that would be a great help to fix and close this issue.
I will keep a look out for a way to reproduce the issue and return, since at this point I don't have one.
Any updates @lhunath?
We are going to close this issue for now, but we can reopen this if you have a way to reproduce the issue, @lhunath.