This naturally confused me and I immediately started assuming something in my code was the cause. My first idea was that the stack cleaner class from Fireye Software (http://fireyesoftware.com/developer/stackcleaner/) was the culprit and was accidently removing the function call from the stack array. Upon review the code in the debugger, however, this was not the case. Literally, on the Mac, the stack array didn't contain the function where the exception occurred.

Let's back up a bit for some history. Back in 2006 Real Software added the stack feature to much acclaim. It no longer meant that you had to have an exception handler in EACH method that contained code. Adding this code was tedious, error prone (think copy and paste errors) and just plain sucked. Before the stack I was using a derivative of BugReporter from http://www.ravenna.com/~forbes/yonk/source/ to send bug reports in to us via email.

I happened to be in the middle of a conversation (via AIM) with an RS engineer and asked him about my experience. The response was somewhat shocking:

You should never rely upon the stack traces as being 100% correct. Stack traces are just a good guess.

So in the long run, you either rely on the stack being 'close enough' and do an inspection to find the culprit or you'll have to add exception handling in every method.

In my Visual Basic 6 days, we didn't even have a stack (and we liked it that way - God I sound old sometimes), but we could have error reporting in every function and track it down to the line level which was handy. We looked at adding some stack trace capabilities but it meant adding two lines of code to every method, function and event in a 950,000 line program and in the long run decided against it.

I digress. So, to guarantee that you know exactly where an exception occurred the only 100% way to do so is to have exception handling in everywhere. It sure would be nice if REALbasic had a method name constant to make doing that fast.

So what are you doing for error reporting?