Home Accessibility Courses Twitter The Mouth Facebook Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Error checking in a Python program - making your program robust via exceptions

Error checking of inputs, in some way, is vital. You may use conditionals such as if, you may precheck data before it reaches your program, or you may do both. But can you be sure you'll meet every eventuality? It's a difficult game forecasting everything that might go wrong. By using excpetions, you can throw a safety net under operations that may potentially fail, catch the failing in the net, and take remedial action.

On our Python courses, we set an exercise during which we ask delegates to "Graham-proof" this piece of code - in other words, modify it so that no matter what I do to the running program, planned, known and reasonable actions will follow.

  first = int(input("First number: "))
  second = int(input("Second number: "))
  print "Sum is "+str(first+second)


And yesterday I wrote a complete sample answer which you can see [here].

The first thing to remember is "if you find yourself repeating code, there must be an easier way" - so rather than sanitise both input lines separately, you should use a function (the alternative of a loop was considered and discarded, since the code could be useful elsewhere in different contexts and programs.). So the equivalent of the three lines above becomes:

  first = getval("First number:")
  second = getval("Second number:")
  print "Sum is "+str(first+second)


My new getval routine reads an input just like the original, but does so within a try block, where I can catch and act on system generated errors - and I've chosen to do so in the following order:
  1. Catch End-of-file errors first as they need a special action - there's little point in trying to read again when there's no data available
  2. Catch all other errors, describing the problem to the user and asking him / her to try again
  3. Catching user generated "break" request (Ctrl-C) and handling them neatly - we decided to make it necessary to press ^C twice to make sure before the program truely exits.


And in with all this work is the need to make a careful decision as to how detailed the information provided to the use who's made an incorrect entry will be. Too little information, and the user's told "you got that wrong" without advice as to how to correct the problem. But too much information, especially the prining of internal error messages and report, and you'll end up with a frightened and confused user. In the sample answer, I've printed out quite a bit of that data as an illustration to the user - who will be a trainee programmer - of the issues that may occur and the data that's available; a classic example of considering the type of customer when you're writing a user interface, and perhaps an extreme solution.

One final note - will your program be run as a stand alone script, or called up from within another script / batch file / make file? You may not know, so it's a good idea as part of your code sanitising exercise to return a success or failure flag to the insticating command prompt / shell / process. At this level of programming, a return status of 0 indicates correct completion, with a value of 1 or higher indicating a failure. And in Python, we use the exit function (formerly sys.exit()) to conclude our operation and report back as appropriate.

(written 2012-03-22, updated 2012-03-24)

 
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articles
Y109 - Python - Exceptions
  [381] Exceptions in Python - (2005-07-17)
  [1042] Nested exceptions in Python - (2007-01-18)
  [1236] Trying things in Python - (2007-06-18)
  [2018] UnboundLocalError - Python Message - (2009-01-31)
  [2281] Python - using exceptions to set a fallback - (2009-07-12)
  [2368] Python - fresh examples of all the fundamentals - (2009-08-20)
  [2408] Robust user input (exception handling) example in Python - (2009-09-17)
  [2622] Handling unusual and error conditions - exceptions - (2010-02-03)
  [2994] Python - some common questions answered in code examples - (2010-10-10)
  [2998] Using an exception to initialise a static variable in a Python function / method - (2010-10-13)
  [3177] Insurance against any errors - Volcanoes and Python - (2011-02-19)
  [3433] Exceptions - a fail-safe way of trapping things that may go wrong - (2011-09-11)
  [3441] Pressing ^C in a Python program. Also Progress Bar. - (2011-09-15)
  [3913] How many times ... has this loco headed west through Tenby? - Python exceptions - (2012-11-05)
  [3930] Reporting the full stack trace when you catch a Python exception - (2012-11-22)
  [4029] Exception, Lambda, Generator, Slice, Dict - examples in one Python program - (2013-03-04)
  [4161] Python varables - checking existance, and call by name or by value? - (2013-08-27)
  [4444] Elements of an exception in Python - try, except, else, finally - (2015-02-28)


Back to
Changing shops and organisations - Melksham, the last and next five years
Previous and next
or
Horse's mouth home
Forward to
Will will smile?
Some other Articles
Kings Cross - new concourse - between Python in Cambridge and Objective C in London
A modern area of Cambridge - some thoughts provoked?
Makefile variables - defined internally, from the command line and from the environment
Will will smile?
Error checking in a Python program - making your program robust via exceptions
Changing shops and organisations - Melksham, the last and next five years
Finding all the unique lines in a file, using Python or Perl
Keeping forum and blog comments clean
A Pivotal Incident - learning how to welcome your guests
Welcome to Melksham - our new communities
4759 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.info/mouth/3664_.html • PAGE BUILT: Sun Oct 11 16:07:41 2020 • BUILD SYSTEM: JelliaJamb