Did some geography for 12th in the morn.
Slow, steady, iterative progress there.

MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

exceptions & assertions

Exceptions

  • What happens when program execution comes across something that it did not expect?
    • like you could go beyond the bounds of a list
    • i try to reference a variable that isn’t there
    • i mix data types. (i dun dis :P 'a'/9)
  • This is basically Python telling me, ‘I don’t get this! Whatcha talkin’ bout Willis?’
  • Python has a whole host of errors, the names of kinda give me clues to what it thinks the problem is. There are
    • SyntaxError (I boo booed typing somewhere, Python does not ‘get’ me)
    • NameError (Can’t find a variable. Did I put it in? Did I call a module correctly?)
    • AttributeError (Errors with classes. Am I calling them wrong?)
    • TypeError (Am I doing string operations on numbers? Or vice versa?)
    • ValueError (Something is wrong with my results. Is it in a form the program understands?)
    • IOError (something that happens when i make boo boos with files)

What do I do with exceptions?

  • Fail silently (like fart silently and then look about innocently)
    • bad idea, though, really bad idea :)
  • Return a “error” value
    • make sure that you have code that can check for and handle the values you choose
    • makes code a little clunkier
  • Just stop execution, and signal an error condition
    • in Python that’s called raising an exception like so,
      raise Exception("Good God! You’re dividing letters with numbers?!")

Dealing with Exceptions. How do I handle them?

  • Use the try & except keywords.
  • As in you’re telling Python, ‘try’ this code. If everything works well, great!
  • But if there’s an error, jump to the ‘except’ clause, and execute what is in there
  • And then carry on with the rest of the program
  • I can then get fancy. I can have multiple except clauses.
    • one to handle typos
    • one to see if my input is valid
    • one to handle division isssue
    • and a final one as a catch all, if all else fails.
  • There is also an else that i can pair with a try
    • the else will execute code if try block it is associated works, with out any exceptions.
    • like ok, try this. all worked? then go that else block and do that thing and then carry on with the rest of the program
    • to my mind it kind of is the main program, because this is the part that always executes.
    • so as I iterate, i keep removing things from try and move them down to the mandatory else clause
  • And then there is finally
    • executed after try, except and else
    • even if they raise errors or cause a break
    • useful for cleaning up after a mess :P (close a file for e.g.)
    • like ok, here’s a booboo, but I better put everything back in it’s place and undo stuff if I can
    • like do no harm.

Exceptions as control flow

  • turn the idea of exceptions on its head
  • instead of waiting for errors and catching them and then raising exceptions
  • we could check ourselves for expected values and raise our own exceptions if results don’t match expectations :)
    • like if i am unable to produce a result that is consistent with the specifications of a function
  • to do that we use raise
  • we raise exceptions
    • like raise iAmDisappointedinYouError("You should have written this better")
    • or more likely you want to raise an existing known error like raise TypeError("You need to enter a number! For the love of God, enter a number!")

Assertions

We can take the idea of proactive exception raising, to another level.
We can defensively program so that we prevent situations that lead to unexpected results.
This idea is what we call an Assertion

  • Remember those docstrings we typed where we expected a certain of inputs and guaranteed outputs?
  • you can think of assertions as the bouncers who enforce them
    • i assert that this should be true. if not, raise an exception
  • you can use the assert statement that in turn will raise an AssertionError if conditions aren’t met
    • could be on inputs (typically, mostly used here)
    • on an intermediate stage of the program
    • if i want to be really careful, i can use it to check output too
  • having these checks makes it a lot easier to locate the source of a bug
    • because if an assert fails, the bug most probably should be just before we called this function
  • Where should you use assertions?
    • so spot bugs as soon as they are introduced and clarify where they happen
    • as a supplement to testing
    • filter and check input
      • check types of arguments or values
      • check that invariants on data structures are met
      • constraints on return values are met
      • violation of constraints on procedure (no duplicates in a list, for e.g.)