Unhandled Exception help

SO i think the answer is here is that the line number guides you to the area you need to look. In my case I eventually found I was using a variable prior to setting. this only triggered when upgrading between versions. 

You won't usually find the exact PC value in the debug.xml file. Instead, look for the line with the largest value that is less than the PC value you decoded to determine the line where the crash is occurring. I can't think of a better way to state that - as an example, you might see:

• 268447503
• 268447539 <- The error is here
• 268447551

Since the PC value in your call stack is 268447546, the largest value in debug.xml less than the value in your call stack is 286447539.

Yes, it can be "between" lines, and is most noticeable if the line is a bit complex.

And when, oh when, will we get the stack report in decimal instead of hex?

The only 'system' reading the error report is human and the only way we use it is to examine the debug.xml.

Why continue to put us through the pain of having to convert hex2dec?

(Or even just tell us the line number directly!)

Very good question. I don't think there's any technical reason why this couldn't be done, but I think we have some technical barriers that would make this change difficult. For example, certain things like ERA viewer and the debugger expect one number format or the other. Regardless, I'll file a ticket to see if we can align the number format used in the call stack and the debug.xml and see what happens.

My suspicion is that this request will either be declined or be low priority because the majority use case is ERA viewer, which handles the decoding for you. The only time hand-decoding comes into play is when working with a side-loaded build of an app that is not on the app store..

And with a side load, you can just build a debug version and get an easy to read stack trace, There is no decoding.

Personally, I'd rather see both in hex than both in decimal.  But I'm also someone who at one time balanced my checkbook (remember those?) in hex.

Brandon.ConnectIQ said:

My suspicion is that this request will either be declined

Thanks for the considered reply. I suspect you're right but I have to demur on this:

Brandon.ConnectIQ said:

the majority use case is ERA viewer, which handles the decoding for you.

ERA has not provided any reports for me for 6 months - and I just don't believe my app is 100% stable!

For me the majority use case is in development when side-loading to test IRL. 

Brandon.ConnectIQ said:

I'll file a ticket

Many thanks (I am surprised that this is the first request!)

Maybe I have missed a useful trick. I use debug extensively, but haven't come across its ability to generate "an easy to read stack trace". Could you elaborate please?

jim_m_58 said:

But I'm also someone who at one time balanced my checkbook (remember those?) in hex.

Ha! I don't believe you!

With "Build for device" you can build a release vseron or one with the debug symbols.  With the debug symbols, in the event of a crash. the statc trace will have file names/line numbers in the stack tract.  With a release version, you just see the pc: values.

Yes, I use the Debug Version when building a test version for the device, which includes an extensive use of the :debug annotation but:

jim_m_58 said:

With the debug symbols,

What are these?