Manually sending Exceptions

[vimception]

The Xamarin Insights SDK has the possibility to manually send an Exception object to the backend. This is very useful in cases where you are able to try/catch Exceptions from which you can recover (show message to user) but would like to have more insights into how and when these occur in a production app. I don't see that possibility in the current mobile center SDK. There is however the possibility to send a test crash (void GenerateTestCrash ();), so I don't see how it could be hard generalizing this to accept an Exception object. The only option I see at this point is to serialize the exception object and to send it as a Analytics event to the backend, which feels like a hack. Am I missing something, is this a feature on the roadmap or is this not considered?

Thanks.

[vimception]

Ignore my comment about generalizing GenerateTestCrash, as I see it just throws an Exception. The idea here would be that the application does not actually crash...

[elamalani]

Hi @langsweirdt

We don't support managed exceptions in Mobile Center at the moment. You are right - there is an option to send it using Analytics event to our backend but it's not ideal. We have plans to support it in the future but unfortunately, I don't have an ETA. If you'd like to know about our product roadmap, please look at this link:

https://docs.microsoft.com/en-us/mobile-center/general/roadmap

[taori]

@elamalani please bump the position of this - this was a highly desireable feature which i loved in xamarin insights. It is also why i genuinely hated hockeyapp - low events limit combined with the necessity to do tracking+error logging in events.

I hope Mobile Center at some point reaches the error resolution capability xamarin.insights did (merging events with error reports to gain additional info about where things went wrong)

[elamalani]

@taori Thanks for the feedback. I'll keep you posted once we support this feature.

[degant]

I can't believe this is still not marked as a feature. Tracking handled exceptions is a rather crucial logging scenario and I would love to use it in our app. Any update on this?

[ghost]

Can you guys provide some examples of what kind of exceptions you are reporting? I heard of examples using this for failed network requests. Anything else you are using this for typically?

It is one thing to report handled exceptions but another to make it useful and meaningful from a service perspective. Exceptions for network errors e.g. contain the URLs which can vary, so we need to implement a specific logic to make this useful.

[taori]

@anlinde Networking, Serialization errors, Custom errors and so on. One way or another - Having to abuse events like in HockeyApp is just gross.

Apart from that for our product uses some custom viewmodel navigation to initialize views as a side product. If such a navigation fails because a view ran into an error, i want to be able to catch such an exception and log it, instead of having to let the app crash just so the exception is being logged as an ordinary crash.

Forcing developers not to catch exceptions to make sure they are logged in analytics certainly isn't the right way to go. As @degant pointed out... It's a crucial feature.

[ghost]

@taori I don't see using analytics for some of these scenarios being "gross". If you want to know if something happens and how often, then custom events is the right tool. If you want to understand what is going on with stack traces, then of a custom event surely won't help. So it depends on what you want to do with the data. Capturing stack traces have performance implications, attaching log files to these kind of errors have even more performance impacts. So it is always a trade-off.

But the exception string is no structured data, so to provide a helpful grouping is not an easy task. Also note that exceptions are not the same on every platform, so what we are globally talking about is reporting errors :)

So am I understanding your goals correctly here?

• How often does a specific type of error occur
• What lead to this error (e.g. via stack traces, previous custom events, your own logs, ...) so you can understand and fix it

In case of network errors, I don't see how stack traces, previous custom events, your own logs can help. You get a 403 on a specific URL with specific parameters. The exception message has that all encoded in a string. We'd need to know the exact formats for this on every kind of platform and every kind of framework to make this useful when using just a reportError module. Does anyone have some examples on how exactly you are using this?

My goal is to understand what you are actually doing, specifically doing. I don't see how "just support reporting custom errors" would be beneficial.

[taori]

@anlinde Regarding "I don't see using analytics for some of these scenarios being "gross"" - That's not what i said though. I said the way it had to be done in HockeyApp felt gross. It was done perfectly fine in Xamarin Insights. However in HockeyApp SDK i did not find any equivalent which seemed as good. Only through forum search i found someone who pointed out that workaround to make error logging happen. That's besides the point however, since Mobile Center will have its own API regarding this future feature i am sure of.

So on topic: In Xamarin.Insights the error logging was just perfect - Indicators of how many errors, what kind of affected devices, how many devices affected by it. An option to change to other instances of this problem with the same stack trace, coupled with an event history, leading to this error, duration of session when the error happened.

Essentially if Mobile Center mirrors the error analytics Xamarin.Insights possessed it will be a top notch developer experience to work with.

Regarding network errors -> I don't want to end up logging errors to analytics and to a different place on the device to make a user upload them manually to us, where we have to tediously find out what made him experience this issue.

I'm not sure what you mean with:

In case of network errors, I don't see how stack traces, previous custom events, your own logs can help. You get a 403 on a specific URL with specific parameters. The exception message has that all encoded in a string. We'd need to know the exact formats for this on every kind of platform and every kind of framework to make this useful when using just a reportError module. Does anyone have some examples on how exactly you are using this?

I could pass on any Exception i wanted to, to xamarin.insights, have it displayed in a dashboard overview, with a view which even strips parts of the stacktrace away, which wouldn't really be useful, because it would just be platform noise.

My goal is to understand what you are actually doing, specifically doing. I don't see how "just support reporting custom errors" would be beneficial.

Let's put it that way. The way i see what Mobile Centers purpose is being Microsofts branch regarding Mobile Development services - not just Analytics for them. While for others analytics might be the main reason people may want to use Mobile Center, for me it is just a side product to see whether or not people even use the features we're developing, to see if it's worth expanding the feature.

The main reason for us however, is to make sure that any potential error a user might experience can be fixed without crashes or disturbance on their side. Xamarin.Insights covered this scenario 100%. Personally i am sad that they do not allow further usage of their advanced features for newcomers to Xamarin.

At its current state if Xamarin.Insights were to completely shut down its services (still using it currently, just a basic version though) and Mobile Center would not support error reporting in a similar fashion, i would actually remove the wrapped analytics calls with the mobile center sdk and remove Mobile Center references entirely, because there is no added value to me in using it.

[ghost]

Thanks for the feedback. The challenge we have is to provide a solution for all supported platforms and programming languages and the way they handle errors and exceptions and the data those provide is quite different. We can't just provide it the same way as Xamarin Insights does it as this is a Xamarin/C# exclusive implementation (backend wise).

We do have this scenario for Mobile Center on the table, but as we are building the service up, there is quite a lot to cover and implement. We've still got quite some way to go which also means priorization of features we implement. Just an example, we are starting to work on alerting (email, webhooks) and issue trackers, also something Xamarin Insights and HockeyApp provide and everyone expects to have, in addition to supporting all the platforms that HockeyApp supports.

We understand that it would be best that everyone gets just what they used to have but that's just not where we are. I also can't comment on the business decisions, but I can say that we are putting a lot of work and thought into making Mobile Center a great next generation products for all. It will just not happen over night.

So the question I am raising here is how are you using handled exceptions in C#, how are you expecting exceptions to be grouped together for the different use cases (based on what information). We are collecting this information also for all other platforms. Then we'll be able to come up with a plan to implement it. We are not there right now, but we want to get there.

In the meantime I got access to some example data for C# users and we'll analyze this.

As for the timeframe, we won't be able to work on this anytime before summer. That's just the reality. Sorry. But again, it is not because we don't want to, we are just not there yet.

[degant]

Hi @anlinde First off, appreciate the prompt response. I cannot argue on the part about having different errors on different platforms which would definitely make it tougher.

But, you've summarized it accurately - as an app dev I would be interested in knowing those two points, how many times an issue occurred and probably the stack trace and exact line where it occurred.

I'll try to describe our scenario for the need for logging exceptions. After a certain point in our app development we saw a significant reduction in app crashes, but that was because we had just handled all sorts of things that could go wrong and added tons of try-catch blocks. Now the user has a better experience - he doesn't have to deal with the ugly crashes and stuff. However the dev team would still love to know what is failing, how many times, if there is a pattern, probably even set up alerts on it and lots of other similar stuff.

What we would love to have would be something similar to Application Insights - since we've been using that a lot for most of our web side logging. They have a simple TrackException method to which you can pass an exception, and then the portal has exceptions grouped by type, problem id etc. which helps us a lot! Link: https://docs.microsoft.com/en-us/azure/application-insights/app-insights-asp-net-exceptions#exceptions

I get it that we can already do the exception logging using Analytics itself and add different useful parts of the complex exception object. That's what we are doing right now since there wasn't a method available to track exceptions. But then again this is such a basic requirement which I think would add value to what Mobile Center Analytics has to offer.

[taori]

Thanks for the feedback. The challenge we have is to provide a solution for all supported platforms and programming languages and the way they handle errors and exceptions and the data those provide is quite different. We can't just provide it the same way as Xamarin Insights does it as this is a Xamarin/C# exclusive implementation (backend wise).

Oh yes. I can perfectly understand that. I would say that the only reason it became that important is because xamarin faded out before Mobile Center is ready to cover all that functionality. I can understand that Mobile Center needs a more generic solution to cover all platforms

We do have this scenario for Mobile Center on the table, but as we are building the service up, there is quite a lot to cover and implement. We've still got quite some way to go which also means priorization of features we implement. Just an example, we are starting to work on alerting (email, webhooks) and issue trackers, also something Xamarin Insights and HockeyApp provide and everyone expects to have, in addition to supporting all the platforms that HockeyApp supports.

We understand that it would be best that everyone gets just what they used to have but that's just not where we are. I also can't comment on the business decisions, but I can say that we are putting a lot of work and thought into making Mobile Center a great next generation products for all. It will just not happen over night.

I can understand that. That is just how product development works. Give the increased difficulty for other platforms i can see how other features are being developed first.

So the question I am raising here is how are you using handled exceptions in C#, how are you expecting exceptions to be grouped together for the different use cases (based on what information). We are collecting this information also for all other platforms. Then we'll be able to come up with a plan to implement it. We are not there right now, but we want to get there.

I can't honestly tell for sure, but i would assume a session based experience regarding error handling would also make sense for the whole platform. While with xamarin i want that session to start on App launch, on the web platform a session start might be used after logging to group custom events with the errors that occur.

In the meantime I got access to some example data for C# users and we'll analyze this.

As for the timeframe, we won't be able to work on this anytime before summer. That's just the reality. Sorry. But again, it is not because we don't want to, we are just not there yet.

No need to apologize. That's just how product development works. You can't have everything at the same time. As long as this feature does ship i am fine :)

[elamalani]

@taori @degant Thanks for sharing your feedback. This is one of the most requested feature in Mobile Center and we have already started looking at it. As Andreas mentioned, we aim at providing the best experience in Mobile Center and as we are building our services, it's just that some features are prioritized before others. That said, we will take your consideration and keep you posted once we set a timeline for supporting handled exceptions.

[rupreetg]

Would love to see this feature in production as soon as possible. I think others have detailed out accurately, just adding my vote for this feature in case you need more votes to make part of your next release :)

[Rashun001]

I agree with @taori Xamarin Dashboard and Exception Logs captured/illustrated the Stack Trace well. I would also add that the 3 platforms (Xamarin Insights, HockeyApp, Azure Mobile) needed a timeline view of events and exception.

Might I suggest a generic exception service, that we could write to? We could convert NSError, NSException, Android and .Net Exceptions as needed.

Not sure if this is the correct threads for the Event Timeline View Feature.

Defects associated to Device Run Profile created in VSTS could help with Reporting and Profiling.

Just a few thoughts and great job!! I just finished migrating from HockeyApp and completely on Azure Mobile.

[ghost]

@Rashun001 please use the chat icon on the bottom right in Mobile Center for feature requests and specific feedback. That way we can easily route it to the appropriate team members.

[moosat]

I would like also to log an exception manually to the crash reports with the stack trace automatically being generated. Instead of using the Analytics. There is an API for Debug Crashes.GenerateTestCrash maybe just to exapand this to release with exception in the parameters

[ghost]

@moosat we do plan to support handled exceptions, but it will take some time. GenerateTestCrash only purpose is to crash your app (it has only a single line of code) so you can test the crash functionality. This has nothing to do with logging handled exceptions ;)

[ederbond]

@anlinde Please COMUNICATE with the Xamarin Insights team and you will find out what are the cenários we need. Just copy the feature exactly how it was on Xamarin Insghts and release it. It's been a pain in the but to leave without it ? If VS Mobile Center was supposed to be the best of both products (Xamarin Insights and HockeyApp) than you guys had to seriouly think about realsing it on day one. THIS IS A MUST HAVE FEATURE!

[ghost]

@ederbond We are aware of this and have it on our list. Mobile Center is still work in progress and doesn't have feature parity to either Xamarin Insights or HockeyApp. We are talking to the people left from Xamarin Insights who worked on this on designing this feature. There is just a lot to do and it is always great to get more background to what is expected.

[jahmai-ca]

My primary use-case is really simple. Every time TaskScheduler.UnobservedTaskException is fired I want a record with the exception stack created in Mobile Center. I DO NOT want to crash my app just to get this information.

[alexsorokoletov]

Wondering, what is the progress on that. I deeply miss that feature from Xamarin.Insights.

[WilliamABradley]

@anlinde @guperrot Is this feature coming in an update soon now that this is officially released?

[guperrot]

Handled exceptions are not yet available, I don't have an ETA yet.

[WilliamABradley]

Its the one thing holding me back from switching from the HockyApp SDK to AppCenter on UWP. When UWP's Crash Reporting from HockeyApp comes through will it contain reported exceptions too?

[ederbond]

Come on @anlinde and @guperrot ? How can you guys launch the product without this basic/must-have feature ? Did you guys have permormed any statistics about how frequent developers used this feature on Xamarin Insights ? (I Could answer by myself: "A LOT !!!"). There is no way to adopt this tool whitout this feature. You guys need to hurry up to implemet it ASAP !!!

[ederbond]

Who the hell is the Product Manager of this product ? We need to tell him to WAKE UP. This issue was opened on Feb 22 and we have nothing on this front !

[Kukkimonsuta]

@ederbond I understand your frustration, but your attitude is not helping anyone. IIRC this feature is present in hockeyapp, so you can use that until it is ready here.

[taori]

@Kukkimonsuta While it's true that his attitude isn't helping i have to repeat that if xamarin.insights were to shutdown now at the time appcenter does not replace it's features in a similar fashion, i would entirely remove all dependencies and figure out my own solution if i can't find one. Compared to Xamarin.Insights hockeyapp was awful last time i used it. XI however has a great API and helped me loads already. Anyone here who keeps calm is probably equally as frustrated (while keeping it cool on the surface) as @ederbond to be honest. Analytics without the ability to manually log exceptions (to be able to reproduce errors in combination with events) is about as questionable as if MS were to replace the built in calculator with one who doesn't support addition and subtraction and told you that they will provide those features in a later release.

Seeing how i'm currently developing our app again and for some reason the insights api isn't responding outside of its apparent mainteanace window (which is normally at 19:45+01 ish), i am getting a bit scared that MS might be planning to shutdown XI - and that would truly be infuriating.

[asierpn]

In my case I go for production with my multi-platform app in a few weeks, I'm using HockeyApp to log UWP handled and unhandled exceptions, but I don't know how to do the same for my Xamarin iOS and Android projects. If you go to Xamarin Insights (the only product I think I can use for this purpose) it redirects you to AppCenter which doesn't support this feature. The error here in my opinion has been replacing XI with AppCenter without migrating first this important feature (the most important for me).

[vlkam]

I'm using HockeyApp to log UWP handled and unhandled exceptions, but I don't know how to do the same for my Xamarin iOS and Android projects.

There is a gist for manually sending the handled exceptions to HockeyApp https://gist.github.com/vlkam/807151a99872240918a1b3351db8cb56

[asierpn]

@vlkam Thanks for the workaround, I will try it.

[ElektrojungeAtWork]

Hey folks,

I'm one of the engineers of the HockeyApp SDKs where we got this feature request a lot in the past when it was first announced that Xamarin Insights would go away eventually – and it is/was not easy for me (and everyone else) to let you guys wait so long. Your frustration is understandable and I'm really torn between "hey, it's amazing that people are using HockeyApp's API as a workaround" and "HockeyApp crash reporting is not meant to be used that way and why does it take us so long to ship this in the first place!?" ;).

But let's stop the blabla. So many people are passionate about handled exceptions and Xamarin Insights. PMs and engineers are reading this thread. As a result, support for handled exception is very important for PMs and engineers on the App Center team. It's gonna happen. Keep the feedback coming.

Benjamin

[WilliamABradley]

@TroubleMakerBen Does this mean that this feature has Priority or will get a time frame soon? Rather than no available ETA? Is it being worked on?

[danilkurkin1]

@vlkam Did have a look at your example - It is sending data and returning 201. However I cannot see those reports on HockeyApp Dashboard. Any tips?

[jahmai-ca]

But let's stop the blabla. So many people are passionate about handled exceptions and Xamarin Insights. PMs and engineers are reading this thread. As a result, support for handled exception is very important for PMs and engineers on the App Center team. It's gonna happen. Keep the feedback coming.

Is further feedback necessary at this point? It's quite clear what the need is, there are even other SDK's to copy from. Saying it's gonna happen is no more information than has already been established on this thread. I thought we were stopping the blabla?

[vlkam]

@danilkurkin1 It's possible if crash log doesn't match hockeyapp format of crash log I copy-pasted two sample crash log, please carefully check your logs https://gist.github.com/vlkam/807151a99872240918a1b3351db8cb56

[danilkurkin1]

@vlkam I have copy-pasted your snippet and also tried to send same data via Postman - same result - HokeyApp saying crash report created but return id=0, delay=0, status=0, so i presume it was not created. Do I have to be paid version member or something? It is damn confusing =S

[ederbond]

Thank you for a good reply @TroubleMakerBen, and sorrys for my furious last comment.

[ElektrojungeAtWork]

@ederbond no worries! =)

Does this mean that this feature has Priority or will get a time frame soon? Rather than no available ETA? Is it being worked on?

Yes, it has priority and you will get a time frame soon! We are working on this.

I thought we were stopping the blabla?

I'm doing my best. =)

Is further feedback necessary at this point?

The thing is: we are working on this. We know that this is MUCH wanted and that people are very passionate about it. So I wanted to signal that we are open for your input. My thoughts about are: Maybe people want to tell us that handled exceptions are important to them (you can always tell us that)? Maybe people want to tell us about their use-case so we can make sure we cover it in testing, etc.? Maybe people are interested in a pre-release of this (not sure if this is gonna happen but we love feedback)? ... That's why I say: keep it coming!

Benjamin

PS: To everyone in the US: happy 🦃 day. =)

[Kukkimonsuta]

@TroubleMakerBen I do have some notes on implementation that I'd love you to consider while working on this.

1) accept and fully display all inner exceptions and well known aggregate exceptions (AggregateException, TargetInvocationException)

System.Net.Http.HttpRequestException: An error occurred while sending the request
   at <snip>
System.Net.WebException: Error getting response stream (ReadDone1): ReceiveFailure
   at <snip>
System.IO.IOException: Unable to read data from the transport connection: Connection timed out.
   at <snip>
System.Net.Sockets.SocketException: Connection timed out
   at <snip>

is much more useful than getting just

System.Net.Http.HttpRequestException: An error occurred while sending the request
   at <snip>

2) we'd love to see an option to use https://github.com/benaadams/Ben.Demystifier or similar mechanic (doesn't need to be built in and should work without explicit support, but please test it out before release?)

[ElektrojungeAtWork]

@Kukkimonsuta This is great feedback. Thanks a lot for this!!!

1. Makes a lot of sense. HockeyApp has support for inner exceptions but there is/was definitely room for improvement there.

2. Sounds very interesting, too. I've forwarded this to the other PMs & engineers that are involved.

[alexsorokoletov]

Glad to see this discussion going forward. Meanwhile we followed recommended approach (use custom events in Analytics to track exception) and turns out that event's properties have max length (64 chars?) for each property so you can't really get whole exception message or stack trace from the event.

Example (see message and stack properties cut

EVENT - Errors.ProcessError - 
{
"message":"Unable to resolve host \"azure-test-api.azurewebsites.net\": No ad",
"type":"IOException", 
"stack":" at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Thro",
"ftype":"Java.IO.IOException"
}

I would really appreciate something that will allow us to track complete exception stack trace of a handled exception using AppCenter.

Thank you.

[rodhemphill]

@TroubleMakerBen We have a crazy situation here where we have to send Insights.Report() calls to log crash reports silently because AppCenter doesn't support manually sending crashes, and send Analytics.TrackEvent() in AppCenter because the "Events" menu item in Insights has been removed. Then we have to manually merge the results of the two systems back together based on time to get a full picture of what events lead up to a crash. Happy to back to Insights until you get AppCenter features complete, but can you advise how I can get the "Events" menu item on the Insights page?

[ElektrojungeAtWork]

Hey @rodhemphill,

this indeed sounds a crazy situation. =( I've pinged the people who can help with Xamarin Insights. Please stay tuned and thx for your patience.

Best, Benjamin

[rodhemphill]

Thanks Benjamin. I'm happy to send our account details, but not on this open thread. Let me know if anything can be done. Regards Rod

[bartdkmediahuis]

How can you make one platform obsolete, start a new platform (with a preview state) and hope people will migrate ? Seems like we need to have a look at crashlytics and other tools after all :(

[ElektrojungeAtWork]

Hey @bartdkmediahuis,

I understand your frustration and the team is reading this thread. Just to be clear:

• App Center is no longer in a preview state.
• App Center is going to have support for managed exceptions very soon and in time before Xamarin Insights "goes away". It's actively being worked.

Please bear with us.

[ElektrojungeAtWork]

@rodhemphill can you send me your account details (app name) via email to BEREIMOL at my employer dot com, please?

[rodhemphill]

On 15 Dec 2017, at 5:15 am, Benjamin Scholtysik (Reimold) <notifications@github.com mailto:notifications@github.com> wrote: