<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
  <head>
    <title>cmdln.net_2008-08-20</title>
    <expansionState>0,4,6,7,16,26,27,34,37,44,49,52,55,57,60,70,73,74,79,84,88,97,98,106</expansionState>
  </head>
  <body>
    <outline text="Intro" Offset="00:17">
      <outline text="Dragon*Con reminder"/>
      <outline text="Interesting discussion on the 8/17 week in review"/>
      <outline text="Questions for audio promo"/>
    </outline>
    <outline text="Word of the Week: dike" Offset="04:00">
      <outline text="http://catb.org/jargon/html/D/dike.html"/>
    </outline>
    <outline text="Hacking 101: Errors and Exceptions" Offset="05:03">
      <outline text="Regardless of what language you are learning, using, need to know how to indicate an error">
        <outline text="You may be able to rely on built in error handling, for common functions"/>
        <outline text="Files, network, etc."/>
        <outline text="At some point, you are going to encounter a problem specific to your own code"/>
        <outline text="Need to understand what is available to indicate errors"/>
        <outline text="Errors are key to intentional programming"/>
        <outline text="You want users, other hackers to be able to understand an error"/>
        <outline text="See Inner Chapter on failures and errors"/>
        <outline text="http://thecommandline.net/2007/01/10/the-command-line-2007-01-10-comment-line-360-252-7284/"/>
      </outline>
      <outline text="In procedural, functional languages, how do you indicate a problem?">
        <outline text="Return a different value, usually one that is obviously not valid"/>
        <outline text="Makes the caller check for valid returns, versus invalid returns"/>
        <outline text="Relies on conventions, documentation"/>
        <outline text="If there is no real return, this can work well"/>
        <outline text="Error code or zero return for success"/>
        <outline text="If there is a real return code, this can get awkward"/>
        <outline text="Many simpler languages bolt together program exit with error"/>
        <outline text="Makes the problem that of the user, not code"/>
        <outline text="So consistent with Unix programs, there are conventions, zero for success, non-zero for failures"/>
      </outline>
      <outline text="Problems with error codes">
        <outline text="Forcing an error value to fit the return type if it is not a simple number">
          <outline text="Could use a wrapper type but is clunky"/>
          <outline text="A union where one part is the valid return, the other the error"/>
          <outline text="Forces a dereference every time, regardless"/>
          <outline text="Makes your code less clear, need to wrap/unwrap or use facilities to do so"/>
          <outline text="Silver lining is you can add more data to the error than just a simple value"/>
          <outline text="Unfortunately, that makes the code more complex, may not be worth it"/>
          <outline text="Could also use a global or a side affect on a struct argument">
            <outline text="Makes the error non-local to your return"/>
            <outline text="Not much different than checking, comparing return value"/>
          </outline>
        </outline>
        <outline text="Structured programming can help further">
          <outline text="Already mentioned wrapper type"/>
          <outline text="Using special structs for errors or error values"/>
          <outline text="Standard C library does this, also has to use a global to precent scoping problems"/>
          <outline text="C does this for exiting out of the program itself"/>
          <outline text="This can still yield errors if you reference the errors incorrectly"/>
          <outline text="Does not help if you want to deal with the problem anywhere other than program exit"/>
        </outline>
        <outline text="Knowing, checking difference between valid return and error">
          <outline text="Constants and enumerations can help"/>
          <outline text="Fixed values against which you can compare"/>
          <outline text="Still doesn't help describe or explain the error directly"/>
          <outline text="Code can break if list of error values grows over time"/>
        </outline>
        <outline text="Multiple places in the code can encounter the same error condition">
          <outline text="If error is tied to program exit, what if you want to try to recover?"/>
          <outline text="A simple return code doesn't say anything about where the error occurred"/>
          <outline text="Again, could use a struct instead of a simple value">
            <outline text="Wasted when the caller doesn't care"/>
            <outline text="Can add complexity, regardless, making building errors harder"/>
          </outline>
        </outline>
      </outline>
      <outline text="Exceptions">
        <outline text="Meant to address many of the issues with error return values, other techniques"/>
        <outline text="A first class object in OO programs">
          <outline text="Can carry additional information, tied to specific sub-type"/>
          <outline text="Creation is usually the same or similar to regular object"/>
        </outline>
        <outline text="Exceptions get thrown, not returned">
          <outline text="Use a special statement to raise or throw"/>
          <outline text="Completes the current scope, just like a regular return"/>
          <outline text="Often can execute a final block, allow unconditional code like resource clean up"/>
        </outline>
        <outline text="Caller uses a different construction to catch them or let them bubble up"/>
        <outline text="Distinct from getting and checking a return"/>
        <outline text="A natural way to express normal completion separate from error completion"/>
        <outline text="Allows errors to be dealt with, if possible, before program exit"/>
        <outline text="In most languages that support, aren't required to catch exceptions"/>
        <outline text="If you don't need to or cannot handle error, just let it keeping going up the call stack"/>
        <outline text="Most exception implementations also capture information from the call stack">
          <outline text="When the same error is reused, tells specifically where the error came from"/>
          <outline text="Usually called a track, like a stack trace or trace back"/>
        </outline>
      </outline>
      <outline text="Error philosophies">
        <outline text="Look before you leap">
          <outline text="Check for any problems ahead of time"/>
          <outline text="Are the inputs valid?"/>
          <outline text="Is the state of the system correct?"/>
          <outline text="Are the side effects, return value correct?"/>
        </outline>
        <outline text="Formal version, to the extreme, design by contract">
          <outline text="http://en.wikipedia.org/wiki/Design_by_contract"/>
          <outline text="Gives names to all the particular aspects"/>
          <outline text="Means the program fails early, consistently"/>
          <outline text="If the developer understands the full contract, understands how to diagnose, repair very specifically"/>
        </outline>
        <outline text="Can you really anticipate all of the problems ahead of time?">
          <outline text="When failure is expensive, makes sense"/>
          <outline text="Like rolling back a transaction"/>
          <outline text="For a library, helps communicate expectations"/>
        </outline>
        <outline text="Ask forgiveness rather than seek permission">
          <outline text="With a rich error mechanism like exceptions, just let errors happen"/>
          <outline text="Relies on complete, clear descriptions"/>
          <outline text="Assumes most errors really cannot be recovered from"/>
          <outline text="Makes sense when cost of error is cheap"/>
          <outline text="Is the reason why many, if not most, exceptions are unchecked, do not need to be caught"/>
        </outline>
        <outline text="As much as DbC appeals, I increasingly lean towards ask forgiveness"/>
        <outline text="Intentional programming helps make up the difference"/>
        <outline text="Be clear, explain well why the error happened, even provide guidance on how to correct"/>
      </outline>
    </outline>
    <outline text="Outro" Offset="27:52">
      <outline text="Contact me">
        <outline text="Email to feedback@thecommandline.net"/>
        <outline text="Web site at http://thecommandline.net/"/>
        <outline text="IM to command.line@skype"/>
        <outline text="Listener comment line is 240-949-2638"/>
        <outline text="del.icio.us tag is &quot;for:cmdln&quot;"/>
        <outline text="http://twitter.com/cmdln"/>
      </outline>
      <outline text="I'd like to thank libsyn.com for AAC hosting and Wouter de Bie for MP3 hosting"/>
      <outline text="These notes and the show audio and music are covered by a Creative Commons license">
        <outline text="http://creativecommons.org/licenses/by-nc-sa/3.0/us/"/>
        <outline text="Attribution, non-commercial, share alike"/>
      </outline>
    </outline>
  </body>
</opml>
