BBC BASIC Programmers' Reference

User Tools

Site Tools

Trace:
debugging_20techniques_20_28lbb_29

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
debugging_20techniques_20_28lbb_29 [2018/04/03 19:26] – [Conditional breakpoints] jackkellydebugging_20techniques_20_28lbb_29 [2024/01/05 00:22] (current) – external edit 127.0.0.1
Line 18: Line 18:
  
 However, most semantic errors cause only an unexpected, undesirable result in the program output or behavior. These are the errors that are most difficult to find and correct. These are the errors that programmers really mean when they refer to a “bug”. However, most semantic errors cause only an unexpected, undesirable result in the program output or behavior. These are the errors that are most difficult to find and correct. These are the errors that programmers really mean when they refer to a “bug”.
- 
- 
- 
- 
- 
  
 =====Good Techniques===== =====Good Techniques=====
Line 77: Line 72:
 The previous scenario is an ideal oversimplification. This was a case when the error caused something observable to happen that was not expected. The opposite can also occur. The error could cause something NOT to happen that was expected. In this case you still need to set a breakpoint and look at the variables. But now you have to analyze the program logic to determine which line of code was supposed to make the action happen, and set the breakpoint there. Hopefully it is in the small module that you just added. The previous scenario is an ideal oversimplification. This was a case when the error caused something observable to happen that was not expected. The opposite can also occur. The error could cause something NOT to happen that was expected. In this case you still need to set a breakpoint and look at the variables. But now you have to analyze the program logic to determine which line of code was supposed to make the action happen, and set the breakpoint there. Hopefully it is in the small module that you just added.
  
-Every program and every error is unique. There is no way to reduce the debugging process to a mechanical checklist. There are things we can do that are sometimes effective, but he debugging process is completely subjective. It depends on knowledge, skill, logic, observation, and intuition. Don’t be disheartened – it IS possible to debug, and even to enjoy it. Remember what they say, "If you truly like your job, you also like its mundane and difficult aspects too."+Every program and every error is unique. There is no way to reduce the debugging process to a mechanical checklist. There are things we can do that are sometimes effective, but the debugging process is completely subjective. It depends on knowledge, skill, logic, observation, and intuition. Don’t be disheartened – it IS possible to debug, and even to enjoy it. Remember what they say, "If you truly like your job, you also like its mundane and difficult aspects too."
  
  
Line 92: Line 87:
  
 For example: For example:
 +<code lb>
    statictext #win.debug, "Debug Line", 0, 0, 785, 17    statictext #win.debug, "Debug Line", 0, 0, 785, 17
    #win.debug "!Font Arial 10"    #win.debug "!Font Arial 10"
    #win.debug ”a$="; a$; ” n=”; n    #win.debug ”a$="; a$; ” n=”; n
    wait ’xxx    wait ’xxx
 +</code>
  
 ===== MainWin ===== ===== MainWin =====
Line 102: Line 98:
  
    
-===== Conditional breakpoints =====+===== Conditional Breakpoints =====
  You might find that a line in a loop is possibly causing the error. Your program might loop through this line any number of times but analysis tells you that only the third iteration is problematic. You can set a conditional 'trace 2' or 'wait' breakpoint that will only stop the program on the third pass through the loop. For example: **if n=3 then wait**  You might find that a line in a loop is possibly causing the error. Your program might loop through this line any number of times but analysis tells you that only the third iteration is problematic. You can set a conditional 'trace 2' or 'wait' breakpoint that will only stop the program on the third pass through the loop. For example: **if n=3 then wait**
  
Line 108: Line 104:
  
  
-===== If all else fails ===== +===== If all else fails... ===== 
- If you've spent many hours and haven't been able to find the cause of an error or to correct it, then STOP. Take a break, do something else to get your mind off it, or get a good night's sleep. When you go back to the problem it's not unusual for the answer to jump right out at you. It happens all the time.\\ \\ + If you've spent many hours and haven't been able to find the cause of an error or to correct it, then STOP. Take a break, do something else to get your mind off it, or get a good night's sleep. When you go back to the problem it's not unusual for the answer to jump right out at you. It happens all the time. 
 + 
 ===== Debugging Exercise ===== ===== Debugging Exercise =====
 You have written a short program and it is working well.  You have written a short program and it is working well. 
 +<code lb>
   NoMainWin   NoMainWin
   WindowWidth = 800   WindowWidth = 800
Line 146: Line 145:
       end       end
   end sub   end sub
 +</code>
 However, you decide it needs a small modification. You want to add a 'Pause' button which will stop the counting. Clicking the 'Start' button will resume the counting where it left off. I've made it easy for you to add your modification. Just un'rem' three lines -- one for the button, and two for its click routine. However, you decide it needs a small modification. You want to add a 'Pause' button which will stop the counting. Clicking the 'Start' button will resume the counting where it left off. I've made it easy for you to add your modification. Just un'rem' three lines -- one for the button, and two for its click routine.
  
debugging_20techniques_20_28lbb_29.1522783596.txt.gz · Last modified: 2024/01/05 00:18 (external edit)