On Tuesday, March 22, 2016 at 10:02:41 AM UTC-4, BartC wrote:
> 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.)
We can certainly improve on this:
while True:
filename = input("Filename (press enter to quit)? ")
if not filename:
break
print("Trying to open: {}...".format(filename))
try:
s = readstrfile(filename)
except Exception as e:
print(" There was a problem opening {}: {}".format(filename, e))
else:
print(" {} has {} characters".format(filename, len(s)))
Some detail of the problem is now displayed. In your code,
there's no information about what was wrong with the filename.
Was it an invalid filename for the OS? Was the file there but
the permissions prevented you from reading it? There's no way
to know. With the exception-based code, we have the message from
the exception itself to provide the details.
> 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?
It doesn't *have* to be exceptions. But they are greatly preferred.
They don't clutter the semantics of your return value, and they prevent
accidents by omission.
> 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.)
Of course a function can still return True or False, if that's a reasonable
semantic. For example, os.path.exists(filename) returns a True or False.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
