diff options
| author | Owen Jacobson <owen.jacobson@grimoire.ca> | 2015-07-03 22:31:49 -0400 |
|---|---|---|
| committer | Owen Jacobson <owen.jacobson@grimoire.ca> | 2015-07-03 22:35:09 -0400 |
| commit | 76aed6ef732de38d82245b3d674f70bab30221e5 (patch) | |
| tree | d50e9a296d91ef8a49bcb29c3e80096f200a3c26 /.html/dev/debugger-101.html | |
| parent | 92f66d3e3a0996bb1fad9dc83d7e184f92673e5d (diff) | |
Fuck it, serve the files directly.
Diffstat (limited to '.html/dev/debugger-101.html')
| -rw-r--r-- | .html/dev/debugger-101.html | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/.html/dev/debugger-101.html b/.html/dev/debugger-101.html new file mode 100644 index 0000000..a19476a --- /dev/null +++ b/.html/dev/debugger-101.html @@ -0,0 +1,178 @@ +<!DOCTYPE html> +<html> +<head> + <title> + The Codex » + Intro to Debuggers + </title> + + <link + rel='stylesheet' + type='text/css' + href='http://fonts.googleapis.com/css?family=Buenard:400,700&subset=latin,latin-ext'> + <link + rel="stylesheet" + type="text/css" + href="../media/css/reset.css"> + <link + rel="stylesheet" + type="text/css" + href="../media/css/grimoire.css"> +</head> +<body> + +<div id="shell"> + + <ol id="breadcrumbs"> + + <li class="crumb-0 not-last"> + + <a href="../">index</a> + + </li> + + <li class="crumb-1 not-last"> + + <a href="./">dev</a> + + </li> + + <li class="crumb-2 last"> + + debugger-101 + + </li> + + </ol> + + + + <div id="article"> + <h1 id="intro-to-debuggers">Intro to Debuggers</h1> +<p>(Written largely because newbies in <a href="http://evanchooly.com">##java</a> never seem +to have this knowledge.)</p> +<p>A “debugger” is a mechanism for monitoring and controlling the execution of +your program, usually interactively. Using a debugger, you can stop your +program at known locations and examine the <em>actual</em> values of its variables +(to compare against what you expected), monitor variables for changes (to see +where they got the values they have, and why), and step through code a line at +a time (to watch control flow and verify that it matches your expectations).</p> +<p>Pretty much every worthwhile language has debugging support of some kind, +whether it's via IDE integration or via a command-line debugger.</p> +<p>(Of course, none of this helps if you don't have a mental model of the +“expected” behaviour of the program. Debuggers can help you read, but can't +replace having an understanding of the code.)</p> +<h2 id="debugging-your-first-program">Debugging Your First Program</h2> +<p>Generally, you start running a debugger because you have a known problem -- an +exception, or code behaving strangely -- somewhere in your program that you +want to investigate more closely. Start by setting a <em>breakpoint</em> in your +program at a statement slightly before the problem area.</p> +<p>Breakpoints are instructions to the debugger, telling it to stop execution +when the program reaches the statement the breakpoint is set on.</p> +<p>Run the program in the debugger. When it reaches your breakpoint, execution +will stop (and your program will freeze, rather than exiting). You can now +<em>inspect</em> values and run expressions in the context of your program in its +current state. Depending on the debugger and the platform, you may be able to +modify those values, too, to quickly experiment with the problem and attempt +to solve it.</p> +<p>Once you've looked at the relevant variables, you can resume executing your +program - generally in one of five ways:</p> +<ul> +<li> +<p><em>Continue</em> execution normally. The debugger steps aside until the program + reaches the next breakpoint, or exits, and your program executes normally.</p> +</li> +<li> +<p>Execute the <em>next</em> statement. Execution proceeds for one statement in the + current function, then stops again. If the statement is, for example, a + function or method call, the call will be completely evaluated (unless it + contains breakpoints of its own). (In some debuggers, this is labelled “step + over,” since it will step “over” a function call.)</p> +</li> +<li> +<p><em>Step</em> forward one operation. Execution proceeds for one statement, then + stops again. This mode can single-step into function calls, rather than + letting them complete uninterrupted.</p> +</li> +<li> +<p><em>Continue to end of function</em>. The debugger steps aside until the program + reaches the end of the current function, then halts the program again.</p> +</li> +<li> +<p><em>Continue to a specific statement</em>. Some debuggers support this mode as a + way of stepping over or through “uninteresting” sections of code quickly and + easily. (You can implement this yourself with “Continue” and normal + breakpoints, too.)</p> +</li> +</ul> +<p>Whenever the debugger halts your program, you can do any of several things:</p> +<ul> +<li> +<p>Inspect the value of a variable or field, printing a useful representation + to the debugger. This is a more flexible version of the basic idea of + printing debug output as you go: because the program is stopped, you can + pick and choose which bits of information to look at on the fly, rather than + having to rerun your code with extra debug output.</p> +</li> +<li> +<p>Inspect the result of an expression. The debugger will evaluate an + expression “as if” it occurred at the point in the program where the + debugger is halted, including any local variables. In languages with static + visibility controls like Java, visibility rules are often relaxed in the + name of ease of use, allowing you to look at the private fields of objects. + The result of the expression will be made available for inspection, just + like a variable.</p> +</li> +<li> +<p>Modify a variable or field. You can use this to quickly test hypotheses: for + example, if you know what value a variable “should” have, you can set that + value directly and observe the behaviour of the program to check that it + does what you expected before fixing the code that sets the variable in a + non-debug run.</p> +</li> +<li> +<p>In some debuggers, you can run arbitrary code in the context of the halted + program.</p> +</li> +<li> +<p>Abort the program.</p> +</li> +</ul> + </div> + + + +<div id="comments"> +<div id="disqus_thread"></div> +<script type="text/javascript"> + /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ + var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname + + /* * * DON'T EDIT BELOW THIS LINE * * */ + (function() { + var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; + dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js'; + (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); + })(); +</script> +<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript> +<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a> +</div> + + + + <div id="footer"> + <p> + + The Codex — + + Powered by <a href="http://markdoc.org/">Markdoc</a>. + +<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/dev/debugger-101.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/dev/debugger-101.md">history</a>). + + </p> + </div> + +</div> +</body> +</html>
\ No newline at end of file |