Include line number of error in Xamarin.iOS app
Bule
Posted on
Oct 27 2015
Hi all, I am using Raygun with a Xamarin.iOS app. The app is already published in the app store. When an error occurs and it is catched by Raygun it is reported in a very general way: - only the name of the method where it happens, but no line number or file name where the error fires. Is this because Debbugging Options is set to false ? Is there a way to get more informations on where the error raise ? If I set debbuging options to true the file became 3 time bigger.
Thanks a lot
Jason Fauchelle
Raygun
Posted on
Oct 27 2015
Hi Bule,
You are correct that the line numbers are missing because of there being no symbols. The only way to get line numbers would be to enable the option that includes symbols in the app. This is not recommended though. We have had a look at possibly using dSYMs to get the line numbers, but that did not work out. We may have another crack at finding a way to get the line numbers of a release app - if possible, but this is not on the immediate roadmap. Apologies for the trouble here.
-Jason Fauchelle
Bule
Posted on
Oct 27 2015
Hi Jason, thanks for your reply. So what do you suggest to find more informations about an error that I can see only in the release app, something I can't reproduce on my own ? Could be an idea to use a try catch on the method which is firing the error and including the stack trace with the RaygunClient.Current.SendInBackground (exception,MyTags,myDetails) ?
Thanks again
Jason Fauchelle
Raygun
Posted on
Oct 30 2015
Hi Bule,
Exceptions that you can't reproduce locally are a pain, and generally difficult to resolve. Your suggestion of sending tags and custom data to gain more state information that can help reproduce the problem is certainly a good next step to take. If you think the exception may be related to the state of a users account, make sure to also send information to look up the user. If your method is quite large, making it difficult to see where the exception is originating from, I'd suggest splitting it into smaller methods, or putting multiple try/catch blocks to narrow down the point of failure.
Hope you can solve this one - if so, I'd be interested to know what the issue was, and what helped you to solve it. Let me know if you have further questions.
-Jason Fauchelle