Skip to content

GitLab

Last edited by Sorrel Harriet
Page history

lab 9

Lab 9: Exception Handling

We are almost at the end of Term 1 of Databases, Networks & the Web.

Here are some of the areas we have covered in previous labs:

  • Essential tools
    • unix shell commands
    • git version management system
  • Web techologies
    • network protocols (SSH, HTTP)
    • web servers
    • request-response cycle
  • Relational databases
    • relational data modelling
    • SQL
    • MySQL Relational Database Management System (RDBMS)
  • NoSQL
    • types of NoSQL database and their applications
    • document data stores
    • MongoDB
  • Python scripting
    • serving Python scripts using CGI
    • database API's
    • form handling / making POST requests
  • Application design
    • Separation of Concerns

By now you should have something ressembling a web application, albeit with fairly minimal functionality.

An area we have yet to consider is one which has strong implications in terms of data integrity, data security and user experience. Can you think what that might be, and how it relates to each of those aspects? (try to resist reading ahead before giving it some thought!)

Task 1: Consequences of poor exception handling

That's right...we'll be thinking about exception handling today, particularly in relation to the handling of HTML form data.

If we fail to anticipate and deal with unexpected user interactions, we may threaten the integrity (reliability) of our data, and/or interrupt a seamless user experience. At worst, we might compromise the security of our data!

That's OK, we'll use JavaScript to validate the form data right?

Right, but...

  • is that enough?
  • if not, why not?

In a small group, consider these questions and discuss the potential consequences of poor error handling.

You will use your answers in tomorrow's game! (so make some notes and don't lose them)

Task 2: More robust exception handling

There are several techniques we can adopt on the server-side to handle problematic form submissions...

  1. Check data is valid

    • Are there any empty fields?
    • If not, are the values of the expected type(s)?
    • If so, are they within the acceptable range (numeric) / in an acceptable format? (strings)
    • Are we also sure there hasn't been any code injection?

  2. Try/Except statements provide a means of handling selected exceptions in different ways. An example from lab-9/login.py...

     try:
         # get the field values from the login form
         username = form['username'].value
         pw = form['password'].value
 except KeyError:
         # handle KeyError's due to missing data
         response = "I don't think you filled all the fields in..."
 else:
         # do this next bit assuming the bit we were `trying' went ok...

  3. If/Else/Elif statements provide a means of controlling program flow according to conditions we specify. There are loads of examples of these all over Catflucks!

  4. Testing! - a robust tesing strategy is essential if we are to achieve a reliable application. Writing modular code can really help in this respect, as it allows us to design and run tests on individual units of funcitonality.

  • Run the Lab 8 example again (if you haven't already run it, you'll probably need to pull the code on your Virtual Server first). How can you cause an error to occur with the login form submission?
  • Now consider your own app implementation, is it also vulnerable to errors?
  • If so, perhaps you can develop the logic so that it anticipates and deals with unexpected user input (i.e. `exceptions')? You may refer to the Lab 9 code for ideas, but I shan't say which bits! ;-)
  • Take a look in the lab-9 folder...what has changed this time? In particular, pay attention to these 2 files:
    • components.py
    • tests.py What do you think has started to happen in tests.py?

Task 3: Room for improvement?

It's the end of term, and Catflucks is by no means complete!

However, it has at least given us an idea about the amount of work involved in developing a data-driven Python app, from scratch, to any reasonable standard...and speaking of standards, what improvements could we continue to make to the Catflucks app?

You might also be forgiven for wondering, why didn't we use a framework?! Well, if you're wondering that, you probably learned something from the laborious process of developing Catflucks. Fortunately, next term, you will get to use frameworks!