Support end user 'onCrash' handling

[mlake]

Looks like KSCrash's onCrash handler is being used up for BugSnag to do its thing. We would like a way to add another handler for recording errors through our own custom tooling.

[ConradIrwin]

We actually hook into its 'on boot after crash' hook. Would that work for
you?

Using onCrash is hard because it has to be async-safe.

Conrad

On Friday, December 26, 2014, Michael Lake [email protected] wrote:

Looks like KSCrash's onCrash handler is being used up for BugSnag to do
its thing. We would like a way to add another handler for recording errors
through our own custom tooling.

—
Reply to this email directly or view it on GitHub
#34.

[mlake]

Hmm...we'd like to record those crashes via Google Analytics as well as bugsnag....previously we would install our own master NSExceptionHandler which would call out to both, but it seems like we would miss out on other KScrash goodness if we did that.

Thoughts?? Michael

On Dec 27, 2014, at 12:48 PM, Conrad Irwin [email protected] wrote:

We actually hook into its 'on boot after crash' hook. Would that work for
you?

Using onCrash is hard because it has to be async-safe.

Conrad

On Friday, December 26, 2014, Michael Lake [email protected] wrote:

Looks like KSCrash's onCrash handler is being used up for BugSnag to do
its thing. We would like a way to add another handler for recording errors
through our own custom tooling.

—
Reply to this email directly or view it on GitHub
#34.

—
Reply to this email directly or view it on GitHub.

[snmaynard]

Perhaps we could combine this with #17 to fix both issues at the same time? Some user code could run before sending a notification with the caveat that it is run out of the context of the crash (next boot)