On 22/03/2016 13:13, Chris Angelico wrote:
On Tue, Mar 22, 2016 at 11:59 PM, BartC <b...@freeuk.com> wrote:
The first step in any program is to write it in the very simplest way
possible. That usually means ignoring all error handling. And yes,
this is true in EVERY language - C, PHP, Pike, DeScribe Macro
Language, you name it. Then you try it, and you find one of two
things:
(Not in C; you can cause serious damage! But when I tried that approach
in my experimental Python programs, it wasn't popular, I recall.)
Note, though, that "deal with" really means "deal with", and NOT
"print oops to the console and terminate". If all you're going to do
with an exception is print and terminate, *let it go*, unless it's a
user-triggered failure, in which case you catch it right at the very
highest level, and basically fall off the end of your program. The
number of times you have sys.exit() in an except clause should be
vanishingly small.
So code like the following is consigned to history?
while 1:
| file = input ("Filename (press enter to quit)? ")
| if file == "": break
| print ("Trying to open:",file,"...")
| s = readstrfile(file)
| if s != 0:
| | print (" ",file,"has",len(s),"characters")
| else:
| | print (" There was a problem opening:",file)
(Oops, ignore the bars.)
And, forgetting file input for a minute, what about function return
values in general; should they still be allowed to return some status or
error codes, or does it all have to be exceptions now?
I mean, is a function allowed to still return True or False, or just
False? (Or perhaps just nothing if the exception mechanism can signal
either.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
