Added reporting of non-fatal conditions

[simonseyer]

I didn't dig into the project too much, so I'm not sure if I missed something here. But in a short test, this worked flawlessly. Would be nice if you would consider this addition.

I read a thread about this topic and it seems that this is planned on your side anyway. In my opinion, it would be very valuable.

[ghost]

Hi,

we don't plan to add support for this in HockeyApp but in the next generation product Mobile Center. As fatal and non-fatal data can be distinguished in the backend, as each app has an API limit of 60 requests/minute, and there are usually way more non-fatal reports, we wouldn't recommend adding or using a functionality like that in HockeyApp this way. Because in the end you will receive less of the more relevant crash reports.

In addition your pull request wouldn't provide any stack trace details, which makes the use of this less helpful.

Best,
Andreas

[simonseyer]

Hi Andreas,

thanks for your response. We are planning to use this for a very specific non-fatal condition only. This should allow us to use it without a negative impact on the normal crash reporting. The AppNotTerminatingCleanlyDetection, which we have activated, is firing a lot more often than we expect our report to be sent.

Having this said, it seems rather strange to me that crashes are silently dropped (which is the case, I guess?) when reaching the API limit. This is something I didn't come across so far and I'm wondering, what are the reasons for this and if it couldn't be handled more gracefully?

I'll check out what you guys are building with the Mobile Center. Is this already in a production-ready state?
Feel free to close this PR.

Cheers,
Simon

[ghost]

Mobile Center is in Preview and we are working on it heavily. We are not yet production ready and don't have feature parity with HockeyApp yet.

The API limit means you can get about 90k crashes/day at max. The SDK will simply send the report later if at any time the server got too many in a short time.

Ok, not entirely sure how you would use this feature when saying it should fire less often than AppNotTerminatingCleanlyDetection. Are you saying your app is killed a lot because of things blocking the main thread and watchdog jumping in?

Having it as a main feature would require us to provide this also on all platforms and provide guidance on how to use it. And handled errors are expected to provide more data and happen more often.

Just want to be clear about the consequences. Appreciate the pull request a lot! :)

[ElektrojungeAtWork]

Hi Simon,

thx for this. I'm leaving this open for a few days, so you have a chance to respond and we can discuss some more.

Thx for the PR! =)

[simonseyer]

Mobile Center is in Preview and we are working on it heavily. We are not yet production ready and don't have feature parity with HockeyApp yet.

Cool, looking forward to using it.

The API limit means you can get about 90k crashes/day at max. The SDK will simply send the report later if at any time the server got too many in a short time.

Ok, got it. Makes sense. And it makes me even more confident, that the solution in this PR is the right one for us.

Ok, not entirely sure how you would use this feature when saying it should fire less often than AppNotTerminatingCleanlyDetection. Are you saying your app is killed a lot because of things blocking the main thread and watchdog jumping in?

Unfortunately, yes. Right now we are required to use a certain library which has some issues when the reception is bad. It seems that the memory usage is growing infinitely in some cases until our App is killed by the system. It is really annoying but we weren't able to get our hands on what is happening and the support of the library owners is really scarce. And since it is closed source our possibilities are limited. Let's hope we find the issue somehow soon ... :-)

Having it as a main feature would require us to provide this also on all platforms and provide guidance on how to use it. And handled errors are expected to provide more data and happen more often.
Just want to be clear about the consequences. Appreciate the pull request a lot! :)

Totally understandable. Thanks for laying out your point of view and clarifying things. Appreciated your feedback!

thx for this. I'm leaving this open for a few days, so you have a chance to respond and we can discuss some more.

Thank you. Maybe it even makes sense to leave it open. This way people who run into the same question can understand the impact and may decide it's the right solution for them. But up to you, of course.

[ElektrojungeAtWork]

Hey @Eldorado234,

Thanks for understanding. I'll keep this open and update this as soon as Mobile Center has support for handled errors/exceptions or whatever the feature will be called.

Thx for using HockeyApp and have a great weekend!
Benny

[jbelkins]

@Eldorado234 I asked HockeyApp to support non-crash failures and they told me no too, so don't feel bad. ;)

FWIW, I have used Bugsnag (www.bugsnag.com) alongside HockeyApp to capture non-crash abnormal conditions, such as NSErrors and NSExceptions. I turn off Bugsnag's automatic crash reporting because I've found Hockeyapp's to be more useful & accurate. HockeyApp and Bugsnag have worked well together (they are based on different crash handling frameworks so there are no link conflicts.) I have used this configuration for about nine months. I, too, would prefer to have one service which handles all of this well, but I have found Bugsnag to be extremely insightful for a lot of production issues that do not crash the app while keeping my HockeyApp crash reporting.

Hope this helps!

[simonseyer]

@jbelkins, thanks for the advice! Right now, we are using a custom fork of the HockeySDK which allows us to send the required events the way it is done in this PR. This fits our needs right now but I'll take a look at the service you suggested anyways. Thanks again.

[ElektrojungeAtWork]

I'm closing this as we're not going to work/release any of this. Stay tuned for more sophisticated non-fatal error reporting at VS App Center.