|
|
|
# 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](https://docs.python.org/3.5/tutorial/errors.html#handling-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! |
