DOC PREVIEW
GT LCC 6310 - Debuggin' Java

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Debuggin' JavaHow do I know my program is broken?Compiler ErrorsSo how do you go about fixing those nasty compiler errors?More about Compile Time ErrorsSo now your program compiles . . .but thenChecked Exceptions (briefly)Unchecked ExceptionsI take exceptionThen there were threeSimple! Just use your 1337 d38u991n9 5ki11zLearn to read your codeSome gotchas that you need to remember when you write codeAnd the #1 debugging tip:Now a quick exampleDebuggin' JavaOr why the *%#@ doesn't my freaking program runcreated by the awesome John GoetzingerHow 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 you get these)●Your program just doesn't do the right thing. –(Uh-oh)Compiler Errors●These are bugs that are most definitely your problem.●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 though.So how do you go about fixing those nasty compiler errors?●Start at the top of the error list–Some errors cause others. (e.g if you mess up a variable declaration the compiler will catch you everywhere the variable is used)–Use the line number! The compiler tells you where the problem is. If that line really does look fine check the line above it, you might have missed a brace/semicolon or other necessary syntax element.More about Compile Time Errors●Some errors aren't necessarily errors.–For example:String foo; //assume we initialize this somewhere elsepublic void blah(){Object bar;try{//I don't know if you know what a Try/Catch block isbar = foo.toString();}catch(Exception e){S.O.P(“Oh no!!”);return;}S.O.P(bar.toString()); //lets call this line 101}–Will give you something like:line 101: variable bar might not be initialized! (or something like that)John’s abbreviation for System.out.println(…); …otherwise known as println(…); in Processing.So now your program compiles . . .but then●There are two types of Runtime Exceptions Checked and Unchecked–Checked exceptions are things that aren't your fault, Java makes you deal with these in your code–Unchecked exceptions aren't required to be caught in code. These are YOUR FAULTChecked Exceptions (briefly)●These are things like IOException (FileNotFoundException for example)●These are things you can't necessarily predict while you write your code and are most likely to be thrown while in the wild which is very very bad.●Java makes you put these in Try/Catch Blocks so you should never really get these unless you screw up those blocksUnchecked Exceptions●These are things that are YOUR FAULT (Java isn't broken)●This includes the dreaded NullPointerException and ArrayIndexOutOfBoundsException (or AIOBE)●Generally these mean you forgot some key part of your code (like initializing a variable, bad loop logic or something similar)I take exception●But these are still nice, because when they occur you get a stack trace!●Just like with compile errors find the first line of the stack trace that occurs in your program. That line is where the bug occurred, not necessarily where the fix is.–On that line look, did you get an NPE? Is there some object that you're calling a method on? Is that object Null? You probably need to initialize it. Is it an AIOBE, check the logic you use to initialize and access the array.Then there were three●What do you do when your program just doesn't work??????Simple! Just use your 1337 d38u991n9 5ki11z●The best friend you'll ever have is System.out.println() (or if you prefer just println() in p5)–Don't worry about using too many when you debug, SOP isn't an endangered species.–Figure out what your variables are initialized to. If its null you will find out. Is that int bigger than the array for some reason? Find out by printing them out!●Sometimes things refuse to print due to java's print logic, if you have problems there is always System.out.flush();Learn to read your code●Luckily Java isn't ABL, you can count on it generally executing one line at a time. You really can read code.–It can help to keep a handy notepad around to keep track of variable values.–This is where comments can really help. If you do something complicated document it!–Try and keep one step to one line. This really helps you figure out whats going on once you sober up.–Format your code! Indentions help readability and can help you find those missing curly braces (but not Moe, Larry or Shemp braces)Some gotchas that you need to remember when you write code●In java Objects are passed by reference and primitives are passed by value.–Simply put, this: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);SOP(temp);SOP(temp2);}prints out:foobar5And the #1 debugging tip:●TEST YOUR CODE OFTEN!!!111oneoneeleven!!–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.Now a quick


View Full Document

GT LCC 6310 - Debuggin' Java

Documents in this Course
Load more
Download Debuggin' Java
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Debuggin' Java and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Debuggin' Java 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?