Debugging / dealing with users

[Foz]

I use a two (or unusually three) pronged approach:

1. Use the OnError - I find that most of the time, just casting a fresh eye over a bit of code that you haven't touched in months will show the problem at hand.

2. Logging of all UI activity with the time - windows opened, windows closed, menu choices, buttons clicked, etc - to the last 1000. Sometimes it's the order of things done that changes variables unexpectedly - one problem that I struggled with for about a year was due to someone changing the program path to "C:\", simply because I'd used the wrong variable, but for most people who left it as the default path it was never a problem. Discovering the process that people do weeds out bugs that you may never consider in your test environment.

3. Create your own "Call Stack" - there are many examples of Stacks implemented in PB - for each Procedure entry and exit, you push and pop your current position in your code - complete with parameter values. I don't usually bother with this one unless something is really ticking me off, but I have done it when I just can't explain what reports I'm getting, and I can't strip out the code and/or make it any simpler. This is of course after using the built in debugger to do the same and I can't repeat it.


A couple of general tips which can help:

- Keep things modular - Try to keep all Procedures self contained - if that isn't possible, and variables have to be shared between several procedures, look up several of the OOP methods that are described here. The aim is that if you are getting errors, you can simple yank out the code and place it in a test app where you can manipulate the variables to your hearts delight.

- Keep Procedure sizes down - break them up if they are large. Smaller chunks of code is a lot easier to debug than a 5 page monstrosity - this also will help with OnError as the thrown error is narrowed down to a small section of code.

- Reduce Globals to a minimum. Yes, I know that they just so damned useful. If you want to keep code modular (easily testable), remove the Globals.

[merendo]

In my opinion, users, especially those who don't use computers very often except when the nature of their work forces them to, expect far too much. Computer technology is rocket science to them, so somehow they expect us programmers to be able to read their minds or magically interpret those indeed useless memory addresses or something (although with the onErrorLines feature enabled, the onError library can at least give you something of a useful clue as to where you might be going wrong in your code). Don't let them pressure you! You are doing the best you can, nothing more could be asked of you. For heavens sake, to err is only human! Remember when Toyota had those massive problems with accelerator pedals getting stuck and vehicles accelerating randomly? Even a business with the resources of Toyota makes errors sometimes and I think they were only able to sort them out after bringing in EMI specialists from NASA. Now compare the size and the resources available to Toyota (or many other major car makers, they have their problems to) to that of yours.

You might want to read this thread which I created some while ago, where I also found Foz's wisdom and experience most valuable (thanks again!): http://www.purebasic.fr/english/viewtop ... 17&t=49092