1 / 21

IAT 265

IAT 265. Debugging. Dialectical Materialism. Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes that

michi
Download Presentation

IAT 265

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IAT 265 Debugging IAT 265

  2. Dialectical Materialism • Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes that • Every economic order grows to a state of maximum efficiency, while simultaneously developing internal contradictions and weaknesses that contribute to its systemic decay IAT 265

  3. Dialectics • Thus, programming is a dialectic process: • ENbugging • Debugging • Karl Marx said so! IAT 265

  4. How do I know my program is broken? • Compiler Errors • easy to fix! • Runtime Exceptions • more difficult to fix, but at least you're using java and these get reported • Your program just doesn't do the right thing. IAT 265

  5. Compiler Errors • Errors dealing with language syntax • Simple logical errors • Whatever the compiler can possibly catch. • Generally, the line number stated has the error on it • Sometimes the fix is elsewhere IAT 265

  6. How to fix compiler errors? • Start at the top of the error list • Some errors cause others • Wrong variable declaration causes errors in usage of that variable • Use the line number! • If that line looks OK, check the line above • maybe missed a brace/semicolon or other necessary syntax element. IAT 265

  7. Count Brackets and Braces { qwdkj { dwwqdlklqwd { n,mnwq } } } 1 2 3 2 1 0 Braces match if the last == 0! IAT 265

  8. Compile Time Errors • Some errors aren't necessarily errors. • For example:String foo; //assume we initialize this somewhere elsepublic void blah(){ Object bar; try{ bar = foo.toString(); } catch(Exception e){println(“Oh no!!”); return; }println(bar.toString()); //lets call this line 101} • Will give you something like:line 101: variable bar might not be initialized! (or something like that) IAT 265

  9. print your variables • println() • Use println often • Print everything: array values, pointer values, array index, objects etc • Each println should label itself with class name and line number • Java: Be sure to use System.out.flush(); to ensure you are getting all data IAT 265

  10. Learn to read your code • Keep a notepad around to keep track of variable values. • Use comments to document complex code • Keep one step to one line. • Format your code! Indentations help readability • Keep your code neat: save your mental effort for understanding, not reading IAT 265

  11. Always the Same Place • My keys are always the same place: • Right front pocket • My Java variables are always the same place • Top of method or top of class • Why? • I always know where to look for variables! IAT 265

  12. Always the Same Place • For loops: always formatted the same • Switch: always formatted the same • Variables: I reuse the same names for( inti = 0 ; i < arr.size() ; i++ ) { ... } • Doing it the same way every time Means: • You don’t have to read the whole for loop IAT 265

  13. Always the Same Place • Here’s what you see: for( inti = 0 ; i < arr.size() ; i++ ) { } • Here’s what I see: for( inti = 0; i < arr.size() ; i++ ) { } • Here’s what I see when something’s missing: forinti = 0 ; i < arr.size() ; i++ ) { } IAT 265

  14. Always the Same Place • Doing something the same way allows me to notice when something is different IAT 265

  15. Runtime Exceptions • There are two types of Runtime Exceptions • Checked and Unchecked • Checked exceptions: • Java makes you deal with these in your code • Things that you would expect to fail: I/O mainly • Unchecked exceptions • Java does not require you to catch these IAT 265

  16. Checked Exceptions • IOException (FileNotFoundException) • Input and output is typically hard to write because you have to deal with the real world’s complexities • Java requires that you put these in Try/Catch Blocks • Processing manages some of this IAT 265

  17. Unchecked Exceptions • Exceptions that only the programmer can anticipate • Extremely hard for a compiler to determine • NullPointerException (NPE) and ArrayIndexOutOfBoundsException (AIOBE) • Caused by semantic errors • uninitialized variable, bad loop logic… IAT 265

  18. Exceptions • On exception, you get a stack trace • Find the first line of the stack trace that occurs in your program. • That line is where the exception occurred, not necessarily where the fix is. • On that line, did you get an NPE? • Is there some object that you're calling a method on? Is that object Null? • For AIOBE, check index values IAT 265

  19. Things to remember • In java Objects are passed by reference and primitives are passed by value. public void doStuff(String a) { a = a + “bar”; } public void doMoreStuff(int a) { a = a+5; } public static void main(...){ String temp = “foo”;int temp2 = 5;doStuff(temp);doMoreStuff(temp2);System.out.println (temp);System.out.println (temp2);}prints out:foobar 5 IAT 265

  20. The #1 debugging tip • TEST YOUR CODE OFTEN! • Catching your small errors early will help you avoid the big complicated errors later. • If you write a chunk of code that you can test, test it. • You'll regret not spending 5 minutes writing a simple test case when you spend hours trying to find out it has a bug later. IAT 265

  21. Wrong and Right • Build • Build • Build • Build • Build • Build • Test • Build • Test • Build • Test • Build • Test • Build • Test IAT 265

More Related