Development Team Blog

You know when there's a program error, and you get that pesky error dialog that says something like Error foobar Technical Details Error Number 1234 Instruction Address 5678, and an OK button. So you think to yourself, great, there's an error in the program, now what? If you're lucky enough, this happens during development while you're debugging, before anyone else sees the problem. If you're not so lucky it happens at a customer site. When this happens at a customer site, you can try to get them to jot down the instruction address that's displayed. Who's done that by the way? What do you do with that address? Well, as most VDF developers know, this can be traced back to a source line in your program. But all too often this is a pretty low number, and as most developers also know, this means it's a line somewhere in the standard system packages, and it will do nothing to help you find the problem. Here's where the new Error Dialog in Visual DataFlex 2008 14.1 comes in and saves the day.

Visual DataFlex 14.1 has overhauled the error display system. Instead of one dialog to handle both user errors (e.g. out of stock, can't place that order) and reporting of program bugs (error 98 - invalid message msg_foobar), we finally separated the two. How that is separated, and how you can fine tune that, is a different story for another day. This article will focus on program errors which are usually bugs, and how they are reported in a manner that will make it much easier to track them down and fix them in your program. This type of errors are referred to as unhandled errors. And there is now a new dedicated error dialog for unhandled errors.

The new error dialog in Visual DataFlex 14.1 for unhandled errors presents a very different user interface from user errors. This is intentional to distinguish it from user errors, and to also present more detailed technical information that are more useful to the developer in tracking down and fixing the bug. The dialog also contains a Copy button, which unsurprisingly copies all the technical information to the clipboard, so the user can easily paste it and send the information to the developer via email or something.

How the Callstack can Help You Track Down the Bug
The main thing is that this dialog now contains the callstack instead of just a single instruction address. This allows you to track down not only the line of code where the error occurred, but the path of execution the program took to get there. If you're an avid user of the integrated debugger in the Studio, you'll recognize that it's essentially the same information that is displayed in the callstack window while debugging. This is like forensic evidence to a developer. The callstack tells you the story of how the program got into the mess that displays the error.

What do you mean? It's just a bunch of stupid text that says blah blah at instruction blah blah over multiple lines, how can that help me finding the bug? The callstack gives you contextual information about the problem. It's like the difference of saying "ouch my foot hurts" vs."ouch my foot hurts after this bug bit me, which looks like this, and I was around in this area over here which is known to be inhabited by this type of bug."

OK, enough, show me something real. Alright. For example:



This tells us that there was an error instantiating some ActiveX control at instruction 2117. Now, instruction 2117 is some line in windows.pkg. Does that mean that there is a bug in windows.pkg? No, not really. It's some object that's calling that code, and that's where it just happened to detect the problem. But the error message tells us absolutely nothing about which object this problem occurred in, or what the program was doing when the problem occurred.

Now, in 14.1 you get a dialog with this information instead:



Notice how the top line in the callstack refers to the same instruction address where the error occurs. But it also gives you the name of the message, and even the name of the object. This tells us right there that this error occurred for the oOrderCalendar object. So in this case it was easy, we figured it all out by just looking at that. But we can learn more from the callstack. You can also see that the error occurred in Page_Object. Furthermore when you look at the next line, you can see how Page_Object was called, and you can follow the thread of execution all the way back.

The Callstack is Better Than a Message Trace
So the callstack isn't a trace of everything that has happened in the program since it started. It's a snapshot of what is happening right now. Every level in the callstack shows what the program is doing right now, not what happened before, but what it's doing right now. It's sort of like when you do a Step Into in the debugger, and you step into the method that you're calling, and you look back at the method that is currently calling you. At each level, you see what the program is doing right now, just at a different level. So for example, OnComExecute is executing in the oCJCommandBarSystem1 object, that's happening right now. But as part of its implementation, it's calling Execute in a menu item object. And so on through Activate, which calls Add_Focus and finally Page_Object in the oOrderCalendar object. So from this you can conclude that the user invoked that specific menu item, which activates that specific view, which finally calls Page_Object in the oOrderCalendar object.

As you can see, this tells us quite a bit about what the program was doing when the error occurred. The trick is to understand how to interpret the callstack to unravel the story. If you then take the callstack and look at it in the context of the source code with the instruction address at each level translated to a source line, you even see at which line it's currently at in each method.

Often this can give you enough information to understand the bug and even fix it. Other times it can give you a better idea as to how to reproduce the problem as you can see what the program was doing while the error occurred. All in all, the callstack is an invaluable tool when tracking down errors. And of course, while debugging you can make even more use of it as you can step back and forth in source interactively. But that's for another topic of debugging. Hopefully you will come to find the new error dialog as much of an improvement and productivity enhancer as we have ourselves. It has saved us a lot of time in tracking down errors reported to us just through the 14.1 alpha and beta process. In some cases we were able to track down bugs which we couldn't have reproduced, yet alone fixed, otherwise. In other cases it has significantly reduced the time it took to find and fix some of the bugs.