On 25/10/14 03:14, boB Stepp wrote:
In the programs I have been dabbling in at work, I am often "surprised" by the situations my users stumble into that I did not have sufficient imagination to consider up front.
That's always a problem. And just when you think you've seen everything the users will astound you by thinking up another way to screw your code. That's one reason for having specialist system test teams completely divorced from the developers. Developers know how its supposed to work so its very difficult for a developer to break their own code. System testers exist to break code, they will not be happy until they have found a way to make it crash or freeze. That's a good thing.
As a user of software I have often wished that the error messages generated were understandable and help me to avoid the condition which triggered that message in the future.
Some people like to raise Python error messages to user level but that can be dangerous. I've had users turn off their PC and call the help desk and wait several hours for help because of a fairly innocuous exception message that spooked them. That cost the business a lot of down time. So translating any uncaught errors into logged messages and displaying something more human friendly on the screen is a good thing IMHO. But that doesn't mean you need to predict every possible
individual error or handle it, that's just not possible, especially in a dynamic language like Python. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor