Algorithms and Data-Structures Exercise Week 0
Outline 1 Introduction Motivation The Example 2 Setting things up Setting command line parameters in Eclipse 3 Debugging Understanding stack traces Breakpoints 4 Final Remarks
Motivation This is supposed to be a reiteration - of course, you already know Java These are useful techniques - you should know them, as they apply to software development in general These are just suggestions - you are free to do it your own way, the result counts
The Example The Traveling-Salesman-Problem Given a set of cities and the distances between them, find the shortest route that visits each city exactly once. Solution This problem is NP-complete - but since it is just an example we use brute force anyway We need to read in a file that gives us the cities and their distances Also, we want to fix a starting city Both, the file and the starting city should be command-line arguments The result is a path - an ordered list of cities we visit
Setting command line parameters in Eclipse Suppose we have written a class CostMatrix that has a static method parse for parsing the input file Then our main could look something like this:
Setting command line parameters in Eclipse If we run this (Run -> Run), we get an error: We have to tell Eclipse to pass the appropriate command-line arguments to our application
Setting command line parameters in Eclipse We can configure this in the Run Configurations:
Setting command line parameters in Eclipse The appropriate tab is fittingly called Arguments: Note that you have to run the program once for Eclipse to generate a default run configuration (it will have the same name as the project)
Understanding stack traces Sometimes there are errors in our programs - if we are lucky, the program crashes Java will present us with a stack trace in this case: Each level of the stack trace represents an active function call at the time of the crash We do not only know in which function the program crashed, but also where this function was called from The larger a program gets, the more valuable this information becomes
Understanding stack traces Since it is a stack trace, the most recent call is at the top (you will learn about stacks in detail later this semester) In Eclipse, you can click on the source-links to get to the point of the error or call Let s look at this stack trace in detail and see what it tells us
Understanding stack traces The error happened in the function CostMatrix.getCost that returns the distance between two cities:
Understanding stack traces This method was called from the overloaded method CostMatrix.getCost that calculates the cost of a route:
Understanding stack traces This method was called from getbestroute:
Understanding stack traces Which called itself recursively:
Understanding stack traces In normal Java-applications, the first call always comes from main:
Breakpoints Unfortunately, this is not enough information to solve the problem We need information about the runtime-state We can get this using the debugger along with a breakpoint A breakpoint marks a point in our program, at which we want to pause the execution in order to inspect the state of the program
Breakpoints To set a breakpoint at a specific line in the code, go to that line (by clicking on the link in the stack trace) and toggle a breakpoint: The dot on the left side indicates a breakpoint on that line
Breakpoints If we execute our program as usual, nothing special will happen, because breakpoints only have an effect in debug-mode:
Breakpoints Eclipse will ask you if you want to switch into the Debug-perspective - you should do that The program will then run until it hits the breakpoint (which will be immediately in our simple example) In the Debug-view (top left), we can see the current call-stack:
Breakpoints In the top right, the Variables-view shows us all variables that are currently in scope, and their current values: This tells us that getcost was just called with the parameters "Berlin" and "Dresden"
Breakpoints If we move one step up in the call-stack (you can click on each call in the current call-stack), we see this: The surrounding call to getcost was called to calculate the total cost for the route [Berlin, Dresden, Hamburg]
Breakpoints First, lets try to reproduce the crash by stepping through the program: Step Over executes the program until the next line of code in the current function (or, if the function returns, it goes on to the point it was called from) Alternatively, we could use Step Into (the symbol left of Step Over), to also step into any functions called in the current line
Breakpoints As we can see, the error did indeed occur: So, what happened in this line? One of the calls to cities.get must have returned null
Breakpoints If we inspect cities in the Variables-view, we see the problem: Neither "Dresden" nor "Berlin" are in cities - this should not happen
Breakpoints So, how to fix this problem? First, check if input data is parsed correctly - this can be done by setting a breakpoint directly after the code that loads the data: Everything looks fine - so apparently, some entries get removed from cities at some point in the program We can go through the program step-by-step to find the line that deletes the cities
Breakpoints This way, we finally find the cause of the problem:
Breakpoints The fix is, to make a copy of cities before modifying it:
Breakpoints In general, we can of course do this without a debugger, by inserting print-statements throughout our code Debuggers take some getting used to, but once you get the hang of it, you will find it much easier and cleaner There are much more features (for instance Watchpoints to break when a variable is accessed or modified)
Extra Hint - Use Assertions! Use assertions to check if certain assumptions or pre-/post-condition are hold true: This assertion will throw an AssertionError if localbestroute does not contain the same amount of cities as cities Assertions are intended to protect you from programmer mistakes (speak your own mistakes)
Resources These slides will be uploaded to the website of this exercise http://icsa.uwgb.edu/~songh/sc/eclipsedebuggertutorial/ There will be a screencast demonstrating the example on the website