CMSC 433 – Programming Language Technologies and Paradigms
Total Page:16
File Type:pdf, Size:1020Kb
Interactive Development Environments CMSC 433 – Programming Language Technologies and Paradigms • A system that covers many development tasks Spring 2007 – Editor – usually with nice syntax coloring, indentation – Compiler – automatic compilation, errors linked to code – Debugger – step through source code Interactive Development Environments – Etc... – Testing, documentation, search, code transformations, ... Feb. 27, 2007 • Examples: Eclipse, DrJava, NetBeans,, Visual Studio, emacs Example IDE -- Eclipse Debugging • Editing • My program doesn’t work: why? – Syntax coloring, auto-indent, brace matching • Use the scientific method: – Integrated with JavaDoc – Study the data • Testing • Some tests work, some don’t – Integrates with Junit testing framework – Hypothesize what could be wrong • Uses suite() or auto-generated suite – Run experiments to check your hypotheses – Interaction panel allows interactive method invocations • Testing! • Debugging – Iterate – Integrates with Java debugger – Interactions panel also useful Starting to Debug Checking that Properties Hold • What are the symptoms of the misbehavior? • Print statements – Input/output – Check whether values are correct – Stack trace (from thrown exception) • E.g., look at value of i to check if i > 0 • Where did the program fail? – Check whether control-flow is correct • E.g., see if f() is called after g() • What could have led to this failure? • Automatic debugger • Test possible causes, narrow down the problem – Allows you to step through the program interactively – Verify expected properties • Don’t need to put in print statements and recompile – Use as part of testing Interactions Panels (e.g., in Dr. Java) Automatic Debuggers • Can evaluate Java expressions interactively • Set execution breakpoints – Can bind variables, execute expressions/statements • Step through execution • Benefits – into, over, and out of method calls – Make sure that methods work as expected • Examine the stack – Test invariants by constructing expressions not in • Examine variable contents program text – Combines with interactive debugger • Set watchpoints – Notified when variable contents change Using the Debugger Tips • Set debug mode to on • Make bug reproducible – Turns on debug panel with state information – If it’s not reproducible, what does that imply? • Set break point(s) in Java source • Zero-into smallest program that reproduces bug • Run the program – Reveals the core problem • Explain problem to someone else (i.e., instructor or TA) – Explaining may reveal the flaw in your logic • Keep notes: don’t make the same mistake twice Defensive Programming Avoiding Errors • Assume that other methods/classes are broken • Codify your assumptions – They will misuse your interface public Vector(int initialCapacity, int capacityIncrement) – Include checks when entering/exiting functions, { iterating on loops super(); if (initialCapacity < 0) • Test as you go throw new IllegalArgumentException( – Using Junit "Illegal Capacity: "+ initialCapacity); ... } – Using the on-line debugger • Re-test when you fix a bug • Goal: Identify errors as soon as possible – Be sure you didn’t introduce a new bug • Do not ignore possible error states – Deal with exceptions appropriately.