Presentation is loading. Please wait.

Presentation is loading. Please wait.

Debugging !!!  ► Believe it or not, errors happen ► The most frustrating part of programming ► Hunting down an error can be harder and more time consuming.

Similar presentations


Presentation on theme: "Debugging !!!  ► Believe it or not, errors happen ► The most frustrating part of programming ► Hunting down an error can be harder and more time consuming."— Presentation transcript:

1

2

3 Debugging !!!  ► Believe it or not, errors happen ► The most frustrating part of programming ► Hunting down an error can be harder and more time consuming than the solution to the original problem ► Debugging tools and methodologies are still in their infancy ► It’s still an art form: must be done manually ► Can’t tell you how to be Da Vinci, but can certainly give you a brush and some paint

4 Just use a debugger! ► Unfortunately, we don’t live in that perfect world just yet ► Several problems with debuggers:  May not be available for several reasons  Don’t work for complex systems like distributed computing  It’s just plain confusing sometimes ► Can be thought of more as reverse engineering than a straight forward process

5 Methodology ► Use your brain… not your fingers ► Keep it simple initially  Look for simple solutions first  The most likely culprit will usually be it ► Move on to more complex solutions ► For the most part, try and assume the computer is doing its job. It’s not wrong ► There are different kinds of bugs to look for

6 Kinds of Errors ► Compile time errors  Usually pointed out to you, easy to fix  Syntactical errors ► Run time errors  “System Errors”: Out of bounds, class cast exception, null pointer exception  “Logic Errors”: No visible errors, you just get the wrong answer ► Causes of Errors  Flawed Logic (semantics)  Typos (syntactical)

7 Thought Process ► Its not working… now what? ► Make sure it is actually a bug ► Was your solution model flawed? ► Are you printing what you want to print? ► Did you forget to save / correct version? ► Libraries are up to date? ► Did you forget to end a comment? ► Was there a crucial input missing?

8 Easy Bugs: Lots of Clues ► How to look for clues? ► Tip: Avoid writing too much before running ► Did a recent change break the code? ► Have you seen this bug before? What did you do in the past to fix it? ► Think first, write down on paper what is going on ► A second set of eyes might be able to see what you are missing. You have been staring at it so long you might miss something simple.

9 More complex problems ► Might be system specific, check manuals ► Narrow down inputs which reproduce the bug. If you know which inputs make it fail you can pinpoint where the error may be. ► Are you close to data type limits? ► Look for suspicious values: Powers of 2, weird ASCII (more applicable in other languages) ► Are your data structures valid? ► Does taking out bits of code make it work? ► Inserting print statements…

10 Foreign/Old Code ► Get a copy of the design / problem statement ► Work it out by hand first ► Group their functions into small bits of readable English: “Formats text”, “Convert hex to binary” ► Know what it all does before attempting to fix it ► Sadly: Complete rewrites often faster than debugging other people’s code ► Look for examples of ‘hard coding’: declared strings, integers, counters which are defined instead of read as input

11 The Art of Print Statements ► System.out.println(“UUUUUUUUUUUUUGH”); ► System.out.println(“YESSSSSSSSSSSSSSSS”); ► Usually best way to find errors in small systems, especially number-based ► Things to print  Counter values  Min/Max values  Array indices  Data structure values ► Where to print  Before / after declarations/initializations  Before / after function calls  Before / after entering loops / recursion  Before “breaking” from a loop

12 Java Specific ► Always give your objects a.toString() or a.toDebug() method ► Make use of Arrays.toString() etc ► print(Index + “ : “ + value) in loops ► Use iterators where possible ► Instead of setting your own parameters for a prebuilt class, override it ► If building GUI/JS, use System.err.println()

13 Examples ► NullPointerExceptions  Print statement after initialization or immediately before passing into functions ► ArrayOutOfBounds  Lucky if you are using java that they are thrown  Print index counters, array values ► Infinite Loops  Do searches for index counter names/updates ► “Wrong answers”  Go over it again by hand, your solution probably is not correct in the first place. Put the code on hold

14 Example: Mathematics ► Sine and Cosine mixed up? ► Negative values? ► Values close to zero / rounding errors? ► Adding small values to large values ► Reversing min / max values? ► Pass by reference / value? ► Loops correct?

15 Examples (ctd) ► Loops / Conditionals ► Are your counters in the right order? ► ++counter vs. counter++ ► Multi dimensional – do it by hand first ► Make sure bracketing matches with indenting ► Copy / Paste changes

16 Life Lessons… ► Format of a file is not standard ascii ► Format of a file is little endian instead of big endian ► Naming conventions actually matter in fortran ► Programming in C for the first time – arrays do not initialize

17 Reverse Engineering ► Start from the error and work backwards ► Make sure all your parts work before testing the system as a whole ► Surround the affected area with output information / line breaks ► Edit lines of ‘fluff’ code out to test the ‘meat’ ► Experiment with different input values ► Fix the code line by line

18 Debugger ► Built into Eclipse for java ► GUI / Text based, same idea ► Only used as a last resort, very time consuming ► Allow for insertion of break lines to halt code execution at any point ► Allow you to see the contents of any object / array / primitive at any time by query ► Amount of data shown often overwhelming ► Doesn’t provide insight into logical error ► Still a manual process to find errors

19 How to avoid ► Don’t write 1000 lines before testing ► Variable names can have meaning ► Don’t hard code ANYTHING. If you must, define all of them in the same place where they are easily seen / changed ► Comment everywhere it isn’t obvious ► If its more than a few lines… put it in a function ► Always use { }

20 Personal Horror Stories ► if (conditional which ran longer than the width of my screen); break; break; ► while (index < end) go from the end of a string to the front… go from the end of a string to the front… index = index -1; index = index -1; ► for (int i=0; i<x; i++) for (int j=0; j<y; i++) ► Forgot about a hard coded n*n matrix read ► Drew background last in graphics class ► Spent 4 hours debugging because C didn’t flush a buffer ► Tried to do anything in fortran or prolog


Download ppt "Debugging !!!  ► Believe it or not, errors happen ► The most frustrating part of programming ► Hunting down an error can be harder and more time consuming."

Similar presentations


Ads by Google