<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="/lib/xsl/devedge-1.00/article_en.xsl"?>
<nde:article 
  url="/viewsource/2003/venkman/01/" 
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:nde="http://devedge.netscape.com/2002/de" 
  xmlns:ent="http://devedge.netscape.com/2003/ent"
  xml:lang="en">

  <nde:header>

    <nde:title>
       Using Breakpoints in Venkman
    </nde:title>

    <nde:category>
      Article
    </nde:category>

    <nde:pubdate year="2003" month="05" day="02"/>
      <nde:summary>
        This article describes breakpoints in JavaScript and how to use 
        the Venkman JavaScript debugger to set and examine breakpoints. 
    </nde:summary>
    
    <nde:channels>
      <nde:channel id="viewsource"/>
      <nde:channel id="javascript"/>
      <nde:channel id="ns-7" />
    </nde:channels>
    
    <nde:keywords>
      JavaScript, Venkman, Debugging, Web Application Development
    </nde:keywords>
   <nde:translations>
      <nde:trans url="/viewsource/2003/venkman/01/index_ja.html" title="Japanese translation of this article">Japanese</nde:trans>
    </nde:translations>
    
    <nde:authlist>
      <nde:author>
        <nde:authname>Robert Ginda, Ian Oeschger</nde:authname>
        <nde:authaffil>Netscape Communications</nde:authaffil>
      </nde:author>
    </nde:authlist>

  </nde:header>

  <nde:head>
   <style type="text/css">
      .chunk { border: 10px; padding: 40px; border: 1px solid lightgray; }
      .what {
              margin-left: 10px;
              font-size: larger;
              font-weight: bold;
          }

      .why {
              margin-left: 25px;
          }

      .left-floating-figure {
              float: left;
              margin: 10px 10px 10px 10px;
              text-align: center;
              font-size: small;
              font-weight: bold;
          }
      .floating-figure {
              float: right;
              margin: 10px 10px 10px 10px;
              text-align: center; 
              font-size: small;
              font-weight: bold;
          }

      .figure-table {
              font-size: smaller;
              border: 1px solid;
      }
   </style>
  </nde:head>

  <nde:content>

<p>This article continues a series of articles on Venkman that began
with <a
  href="/viewsource/2002/venkman/01/">Venkman,
the New JavaScript Debugger for Netscape 7.0</a>.
</p>

<p>One of the basic tasks of debugging any language is setting
<i>breakpoints</i>. Breakpoints are places in code where execution is
suspended. When you set a breakpoint in a debugging application such
as Venkman, you can take advantage of the suspension to examine
variables, objects, and other featues of the execution.
</p>

<p>This article describes breakpoints in JavaScript and how to use
Venkman to set and examine breakpoints. It's divided into two main
sections:
</p>

<ul>
  <li><a href="#basicbreakpoints">Basic Breakpoints</a></li>
  <li><a href="#advancedbreakpoints">Advanced Breakpoints</a></li>
</ul>

<h2 id="basicbreakpoints">Basic Breakpoints</h2>

  <p>The Stop button and <tt>debugger</tt> keyword are useful features
  of the JavaScript debugger, but when you are debugging deep in
  code<ent:mdash/>especially code you have authored yourself and are
  responsible for troubleshooting<ent:mdash/>you're going to need
  breakpoints.
</p>

  <ul>
    <li><a href="#types">Types of Breakpoints</a></li>
    <li><a href="#set">Setting Breakpoints</a></li>
    <li><a href="#debug">Debugging with Breakpoints</a></li>
    <li><a href="#clear">Clearing Breakpoints</a></li>
  </ul>

  <a name="types"></a>
  <h3>Types of Breakpoints</h3>

  <p>Venkman has two types of breakpoints.  The first, and most common, is called
  the "hard" breakpoint. A hard breakpoint represents an actual trap instruction
  included in the pseudocode of a compiled function.  Hard breakpoints can only
  exist in the context of a function currently "live" in the browser.  Hard
  breakpoints are the ones that actually stop program execution.
</p>

  <p>The second type of breakpoint, the "future" breakpoint, represents a promise
  from Venkman to set a hard breakpoint as soon as it is possible. Future
  breakpoints are used when you want to stop in a script that has not yet
  been compiled. The most common use of future breakpoints is to stop in a "top
  level" script (script that executes outside of any function), or script
  that executes during the onLoad event of a page. When a script is loaded
  that matches the URL of a future breakpoint, and has executable code at the
  specified line, Venkman will automatically set a future breakpoint.
</p>

  <p>Except for this distinction, breakpoints in Venkman work like breakpoints in
  most other debuggers.  The dots you see in the left margin of the Source Code
  View indicate which lines contain executable code, places where a hard
  breakpoint can be set. </p>

  <blockquote>
  <img src="venkdot.gif"/>
  <br /><b>Figure 1. Executable Code in Venkman Source</b>
  </blockquote>


  <a name="set"></a>
  <h3>Setting Breakpoints</h3>

  <p>Clicking on one of these dots in the Source Code View will set a breapoint at that line.
  Venkman will stop BEFORE the line executes. When a breakpoint is
  set, the margin will change to the letter "B", as in Figure 2.  If
  you execute this code again after having set this breakpoint,
  Venkman will stop at line 107.</p>

  <blockquote>
  <img src="venkbreak.gif" />
  <br /><b>Figure 2. Setting a Breakpoint</b>
  </blockquote>

  <p>Venkman also indicates that one or more breakpoints have been set
  in the Loaded Scripts View, where red dots appear next to the
  files in which breakpoints have been set, along with the line number
  where the function begins whose code is being stopped.</p>

  <blockquote>
  <img src="venkscriptsdot.gif" />
  <br /><b>Figure 3. File with Breakpoints in the Loaded Scripts View</b>
  </blockquote>

  <a name="debug"></a>
  <h3>Using Breakpoints to Debug</h3>

  <p>When you set a breakpoint, you give Venkman (or whatever debugger
  you're using) the opportunity to display information about the
  execution environment. One of the most important aspects of
  debugging a script or software program is the ability to examine
  variables<ent:mdash/>function return values, errors, counters, variable
  scopes<ent:mdash/>as they change over the course of the script execution.
</p>

  <p>The <tt>DownloadButton</tt> function in Figure 1, for example,
  uses the variable <tt>type</tt> to figure out what kind of build to
  make available underneath the download button. When you set a
  breakpoint at line 113, where the variable is tested when the
  function figures out that the platform is Windows, you can reload
  the web page in the main browser and see Venkman stop execution as
  it enters the DownloadButton function. Stopped there, Venkman displays the
  value of the <tt>type</tt> variable as "milestone" in the Local
  Variables View.
</p>

  <blockquote>
    <img src="venkview.gif"/>
    <br /><b>Figure 4. Local Variables View at a Breakpoint</b>
  </blockquote>

  <p>Using breakpoints and the Interactive View, you can change the
  values of the variables that Venkman displays (only in the context
  of the debugging environment itself) and see how these changes
  affect the execution of the code.
</p>

  <blockquote>
    <img src="venkinteract.gif"/>
    <br /><b>Figure 5. Interacting with the Script at a Breakpoint</b>
  </blockquote>
 
  <p>For more information about the sorts of actions you can take in
  Venkman when you're at a breakpoint, see the <a
  href="../01/#walkthrough">Debugging Basics</a> section of the
  introductory Venkman article.
</p>

  <a name="clear"></a>
  <h3>Clearing Breakpoints</h3>

  <p>To clear the breakpoint, click on the margin twice.  The first click will
  clear the hard breakpoint and leave you with only a future
  breakpoint, which is represented by a yellow letter "F". A
  second click will remove the future breakpoint as well.
</p>

  <blockquote>
    <img src="venkfuture.gif"/>
    <br /><b>Figure 6. Future Breakpoint</b>
  </blockquote> 

  <h2 id="advancedbreakpoints">Advanced Breakpoints</h2>

  <p>Venkman allows you to associate a breakpoint with a script that
  will be executed in the scope of the function when that breakpoint
  is hit. This advanced feature and other options you can see for the associated script are available from the Future Breakpoint Properties dialog, which you can access by right-clicking a breakpoint and selecting Properties.
</p>

<blockquote>
  <img src="venkfuture_dlog.gif"/>
<br /><b>Figure 7. Future Breakpoint Properties Dialog</b>
</blockquote>

  <p>Once you've created a script that will be executed when the
  associated breakpoint is hit, you can select a number of different
  options from the Future Breakpoint Properties dialog that determine
  how Venkman will deal with the output of the
  associated script. The following options are available: 
</p>

<ul>
  <li><b>Continue regardless of result</b> causes Venkman to continue normal execution
  after running the breakpoint script.  This can be useful to try out additional
  code, on the fly.
</li>

  <li><b>Stop regardless of result</b> causes Venkman to stop execution after executing
  the breakpoint script, allowing you to inspect program state.
</li>

  <li><b>Stop if result is true</b> effectively makes this a conditional breakpoint.  If
  the breakpoint script returns a true value (it doesn't have to strictly be
  a boolean <tt>true</tt>, any non-<tt>null</tt>, non-empty string, non-zero, non-undefined,
  and non-<tt>false</tt> value will do), execution will continue normally.  If, on
  the other hand, the script returns a false value, Venkman will stop execution
  at that point.
</li>

  <li><b>Early return from caller with result</b> will cause the function that the
  breakpoint is set in to return the value of the breakpoint script as its
  result, immediatley after the breakpoint script completes.  
</li>

  <li>The <b>Pass exceptions to caller</b> checkbox allows you to pass exceptions thrown
  by the breakpoint script directly to the caller.  Normally, if the
  breakpoint script generates an exception, Venkman assumes you made a mistake
  and stops execution after displaying the exception.  If you would like to
  see what your code does when exceptions are thrown at it, check
  "Pass exceptions to caller", and thrown an exception from the breakpoint
  script.
</li>

  <li>The <b>Log result</b> checkbox tells Venkman you want the result of the script
  to show up in the Interactive Session View.  When used with the
  <b>Continue regardless of result</b> option, the breakpoint can be used as a simple
  log message.
</li>

  <li>The number of times the breakpoint has been hit is passed in as a parameter to
  the breakpoint script.  To reset the count, enter a 0 in the "Trigger count"
  field.
</li>
  </ul>

  <h3>Meta Comments</h3>

  <p>You can alo embed scripted breakpoints directly into the souce
  code you are debugging by using a Venkman facility called <i>meta
  comments</i>. Meta comments are specially formatted comments that
  pull in the script named after the comment and specify how to treat
  the output of that script. The following meta comment types are
  available:
</p>

<ul>
  <li>The <tt>//@JSD_LOG</tt> comment will insert a breakpoint which is set to execute
  the script that follows without stopping.  The result of the evaluation
  will be logged to the Interactive Session.
</li>

  <li>The <tt>//@JSD_BREAK</tt> comment will insert a breakpoint which is set to execute
  the script that follows and stop if the result is true.
</li>

  <li>The <tt>//@JSD_EVAL</tt> command will insert a breakpoint which is set to execute
  the script that follows without stopping and without logging the result.
</li>

  <li>These meta comments can be used to insert debug-only code in your scripts
  with zero impact on prdouction code.
</li>

</ul>
  <p>To enable meta comments in a script, select "Scan for Meta Comments" from the
  context menu of the file in the Loaded Scripts view.
</p>

  <p>When you add a meta comment, a normal breakpoint is created. You can
  change or delete this breakpoint just as you would a breakpoint created by
  hand.
</p>



<h2 id="Resources">Resources</h2>

<p>See the following links for more information about Venkman:
</p>
<ul>
<li>Venkman Homepage: <a href="http://www.mozilla.org/projects/venkman/">http://www.mozilla.org/projects/venkman/</a>
</li>

<li>Venkman Development Page: <a href="http://www.hacksrus.com/~ginda/venkman/">http://www.hacksrus.com/~ginda/venkman/</a>
</li>

<li>Screenshots: <a href="http://www.hacksrus.com/~ginda/venkman/screenshots/?M=D">http://www.hacksrus.com/~ginda/venkman/screenshots/?M=D</a>
</li>

<li>FAQ: <a href="http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html">http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html</a>
</li>

<li>Newsgroup: netscape.public.mozilla.jsdebugger<br />
Newsgroup FAQ entry: <a href="http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#ng">http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#ng</a>
</li>

<li>IRC: irc://irc.mozilla.org/venkman<br />
IRC FAQ entry: <a href="http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#irc">http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#irc</a>
</li>
</ul>

</nde:content>

  <nde:related area="nde">
    <nde:item url="/viewsource/2002/venkman/01/">Venkman, 
      the New JavaScript Debugger for Netscape 7.0</nde:item>
        <nde:item url="/library/releases/netscape-7/">Other Articles about Netscape 7</nde:item>
  </nde:related>
  
</nde:article>
