The code:
print ("pre-chunkLine")
chunks = []
try:
chunks = self.chunkLine (l)
except:
print ("caught exception")
print (sys.exc_info()[:2])
finally:
print ("at finally")
print ("chunks =")
print (repr(chunks), ".", end = ":")
produces this result:
. . ., by
pre-chunkLine
caught exception
at finally
path 3...
Any suggestions as to what's wrong with the code?
FWIW, chunkLine begins:
def chunkLine (self, line):
print ("chunkLine: ")
print ("line = ", line)
if line == None:
return []
assert (isinstance (line, str) )
Can you state more clearly the problem, please? I'm seeing output that
can't have come from the code posted (for instance, immediately after
the "at finally", I'm expecting to see the "chunks =" line), and I'm
not seeing any exception information, so I can't even hazard a guess
as to what's throwing the exception.
Presumably these are two methods in the same class, since you're
calling it as "self.chunkLine", but beyond that, it's hard to know.
Take off the try/except and let your exception go to console, that's
usually the easiest thing to deal with.
>> Any suggestions as to what's wrong with the code?
>> FWIW, chunkLine begins:
>> def chunkLine (self, line):
>> print ("chunkLine: ")
>> print ("line = ", line)
>> if line == None:
>> return []
>> assert (isinstance (line, str) )
On your except line, you forgot both the type of exception you're
expecting and the variable to receive its value. So you're masking all
errors, including a name error finding chunkline().
You don't include enough code to make the fragment executable, so I'd
have to just guess. I'm guessing that chunkline() is not defined in the
same class as that first method, whatever it was called.
If this were my problem, probably first thing I'd try is to remove the
try and catch, and see what it shows. Bare exceptions are the bane of
programming; Using it is like trying to learn to drive while blindfolded.
> On Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
> <charleshi...@earthlink.net> wrote:
>> The code:
>> finally:
>> print ("at finally")
>> print ("chunks =")
>> produces this result:
>> path 3...
> Can you state more clearly the problem, please? I'm seeing output that
> can't have come from the code posted (for instance, immediately after
> the "at finally", I'm expecting to see the "chunks =" line), and I'm
> not seeing any exception information, so I can't even hazard a guess
> as to what's throwing the exception.
I'd expect the output of:
print (sys.exc_info()[:2])
between these two lines:
caught exception
at finally
That suggests to me that "sys" hasn't been imported and that's there's
another exception somewhere that we're not seeing.
> Presumably these are two methods in the same class, since you're
> calling it as "self.chunkLine", but beyond that, it's hard to know.
> Take off the try/except and let your exception go to console, that's
> usually the easiest thing to deal with.
> On 24/06/2012 23:26, Charles Hixson wrote:
>> The code:
>> print ("pre-chunkLine")
>> chunks = []
>> try:
>> chunks = self.chunkLine (l)
>> except:
>> print ("caught exception")
>> print (sys.exc_info()[:2])
>> finally:
>> print ("at finally")
>> print ("chunks =")
>> print (repr(chunks), ".", end = ":")
>> produces this result:
>> . . ., by
>> pre-chunkLine
>> caught exception
>> at finally
>> path 3...
>> Any suggestions as to what's wrong with the code?
>> FWIW, chunkLine begins:
>> def chunkLine (self, line):
>> print ("chunkLine: ")
>> print ("line = ", line)
>> if line == None:
>> return []
>> assert (isinstance (line, str) )
> Don't use a bare "except"; it'll catch _any__exception. Catch only what
> you expect.
> For all I know, it could be that the name "l" doesn't exist.
But what I wanted was to catch any exception. A problem was happening and I had no clue as to what it was. (It turned out to be "self is not defined". A silly mistake, but a real one.)
The odd thing was that if I ran it without the try block, I didn't get any exceptions at all. (Which I clearly should have, except that since self wasn't defined, I'd usually expect the interpreter to detect the error before trying to execute the code.)
<charleshi...@earthlink.net> wrote:
> But what I wanted was to catch any exception. A problem was happening and I
> had no clue as to what it was. (It turned out to be "self is not defined".
> A silly mistake, but a real one.)
> The odd thing was that if I ran it without the try block, I didn't get any
> exceptions at all. (Which I clearly should have, except that since self
> wasn't defined, I'd usually expect the interpreter to detect the error
> before trying to execute the code.)
Python, not having any concept of declared variables, can't detect
such errors prior to execution. The error isn't like in C where you're
trying to use a variable that's not declared; the error is that, at
run time, there's no global with the name "self". That's why it's an
exception, not a compile-time error.
But the real question is: Why do you get no exception traceback if you
remove the try/except? Is something else swallowing everything thrown?
This is something that you will need to solve. (And it's a pretty
annoying issue. We had the same thing here at work, though in
Javascript not Python; a framework was swallowing exceptions, so all
sorts of work was being done blindfolded. Legacy code is not fun. Life
got a lot easier for us last Friday when I found and excised the
offending try/catch.) Hunt around and see if exceptions are getting
logged someplace other than your console - not uncommon if, for
instance, you're running in a web server. This is not going to be the
only time when you get an exception that could be massively helpful.
Mind you, I think every programmer should spend some time debugging
blind. It gives you such an appreciation for interactive debuggers.
Plus, it's an exercise in making your problems reproducible, if you
have to start your program over every time you add some more
information to it :)
> On 06/24/2012 03:43 PM, MRAB wrote:
>> On 24/06/2012 23:26, Charles Hixson wrote:
>>> <SNIP>
>> Don't use a bare "except"; it'll catch _any__exception. Catch only what
>> you expect.
>> For all I know, it could be that the name "l" doesn't exist.
> But what I wanted was to catch any exception. A problem was happening
> and I had no clue as to what it was. (It turned out to be "self is
> not defined". A silly mistake, but a real one.)
If you don't get anything else out of this thread, get this point. A
bare except is exactly the opposite of what you want to debug an
exception. It swallows all the information that python would have
displayed for you.
Four or five of us have made the same point, so please listen.
> On 06/24/2012 03:36 PM, Chris Angelico wrote:
>> On Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
>> <charleshi...@earthlink.net> wrote:
>>> The code:
>>> finally:
>>> print ("at finally")
>>> print ("chunks =")
>>> produces this result:
>>> path 3...
>> Can you state more clearly the problem, please? I'm seeing output that
>> can't have come from the code posted (for instance, immediately after
>> the "at finally", I'm expecting to see the "chunks =" line), and I'm
>> not seeing any exception information, so I can't even hazard a guess
>> as to what's throwing the exception.
>> Presumably these are two methods in the same class, since you're
>> calling it as "self.chunkLine", but beyond that, it's hard to know.
>> Take off the try/except and let your exception go to console, that's
>> usually the easiest thing to deal with.
>> Chris Angelico
> Sorry, but it *DID* come from the code posted. Which is why I was so > confused. I finally tracked it down to "self was not defined" by > altering the except section to read:
> except BaseException as ex:
> print ("caught exception")
> print (ex)
> finally:
> print ("at finally")
The documentation section covering the except statement could stand to be a *LOT* clearer. I read the sections on the except statement and exception handlers several times and couldn't figure out was the "as" argument of the except statement was for. "Target" doesn't communicate much to me. The one I finally used as indicated above was modified from some code that I found through Google. I still don't really know what "as" means, except that if you use it, and you print out the "target", you'll get some kind of informative message. (The one that I got said "self was not defined" .. that's a paraphrase. I can't remember the precise wording.) And that interpretation is based on what the result was, not on anything said in the documentation.
IIRC, the Python2 documentation used code examples to indicate what was the right way to write an exception handler. I realize that Python3 is much different, but that approach was a very good one.
-----Original Message-----
From: MRAB [mailto:pyt...@mrabarnett.plus.com] Sent: 25/06/2012 4:14 AM
To: python-l...@python.org
Subject: Re: exception problem
On 24/06/2012 23:26, Charles Hixson wrote:
> The code:
> print ("pre-chunkLine")
> chunks = []
> try:
> chunks = self.chunkLine (l)
> except:
> print ("caught exception")
> print (sys.exc_info()[:2])
> finally:
> print ("at finally")
> print ("chunks =")
> print (repr(chunks), ".", end = ":")
> produces this result:
> . . ., by
> pre-chunkLine
> caught exception
> at finally
> path 3...
> Any suggestions as to what's wrong with the code?
> FWIW, chunkLine begins:
> def chunkLine (self, line):
> print ("chunkLine: ")
> print ("line = ", line)
> if line == None:
> return []
> assert (isinstance (line, str) )
Don't use a bare "except"; it'll catch _any__exception. Catch only what
you expect.
For all I know, it could be that the name "l" doesn't exist.
> The documentation section covering the except statement could stand to > be a *LOT* clearer. I read the sections on the except statement and > exception handlers several times and couldn't figure out was the "as" > argument of the except statement was for.
I agree that the tutorial doesn't explain the use of "as" very well, but
it does cover that a bare except is not normally good to use:
"The last except clause may omit the exception name(s), to serve as a
wildcard. Use this with extreme caution, since it is easy to mask a real
programming error in this way!"
> I still don't really know what > "as" means, except that if you use it, and you print out the "target", > you'll get some kind of informative message.
"as" lets you refer to the exception object that was caught. I find this
useful mainly for exceptions that have attributes (most built-in
exceptions don't, but many user-defined exceptions do). A full traceback
is much more useful for debugging than what a simple print(exc) will give.
There are a few different ways to get traceback information without
letting the exception simply propagate and terminate the program. You
can get some simple information from sys.exc_info() (and you can feed
the traceback object to a function in the traceback module), or you can
log it with the logging.exception() function or the exception() method
of a Logger from the same module. I recommend using logging. However,
it's generally best to just let any unexpected exceptions propagate
unless the program absolutely must continue, especially when debugging.
-- CPython 3.3.0a4 | Windows NT 6.1.7601.17803
On Sun, 24 Jun 2012 18:45:45 -0400, Dave Angel wrote:
> Bare exceptions are the bane of
> programming; Using it is like trying to learn to drive while
> blindfolded.
+1 QOTW
I really wish bare exceptions were removed from Python 3. There's no point to try...except any longer, and it's just an attractive nuisance to beginners.
On Sun, 24 Jun 2012 16:16:25 -0700, Charles Hixson wrote:
> But what I wanted was to catch any exception.
Be careful of what you ask for, since you might get it.
"Catch any exception" is almost certainly the wrong thing to do, almost always. The one good reason I've seen for a bare except is to wrap the top level of an application in order to redirect uncaught exceptions to something other than the console (such as a GUI error dialog box). And even then, you probably don't want to catch *all* exceptions, but only those that inherit from Exception:
try:
main() # run my application
except Exception as err:
display_error_dialog(err)
# or log to a file, or something...
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 25 Jun 2012 09:51:15 +1000, Chris Angelico wrote:
>> Mind you, I think every programmer should spend some time debugging
>> blind.
> You're a cruel, cruel man.
> I suppose next you're going to say that every programmer should spend
> some time programming using Notepad as their only editor.
No no, that's just *too* nasty.
But there are times now and then when, perhaps, you're working
remotely, and you have to figure out what's wrong without exception
tracebacks. Sure, 95% of programmers will never be in that situation,
but it's a good skill to have. And when that disaster _does_ strike
and you're stuck with just a file uploader and a crashing script,
you'll look awesome for being able to fix it in five minutes flat :)
>> The documentation section covering the except statement could stand to
>> be a *LOT* clearer. I read the sections on the except statement and
>> exception handlers several times and couldn't figure out was the "as"
>> argument of the except statement was for.
> I agree that the tutorial doesn't explain the use of "as" very well, but
> it does cover that a bare except is not normally good to use:
> "The last except clause may omit the exception name(s), to serve as a
> wildcard. Use this with extreme caution, since it is easy to mask a real
> programming error in this way!"
>> I still don't really know what
>> "as" means, except that if you use it, and you print out the "target",
>> you'll get some kind of informative message.
> "as" lets you refer to the exception object that was caught. I find this
> useful mainly for exceptions that have attributes (most built-in
> exceptions don't, but many user-defined exceptions do). A full traceback
> is much more useful for debugging than what a simple print(exc) will give.
> There are a few different ways to get traceback information without
> letting the exception simply propagate and terminate the program. You
> can get some simple information from sys.exc_info() (and you can feed
> the traceback object to a function in the traceback module), or you can
> log it with the logging.exception() function or the exception() method
> of a Logger from the same module. I recommend using logging. However,
> it's generally best to just let any unexpected exceptions propagate
> unless the program absolutely must continue, especially when debugging.
I read that that would happen, but " print (sys.exc_info()[:2]) " didn't even yield a blank line. It must have executed, because the print statement on the line before it executed, and there wasn't a loop or a jump (and also execution continued "normally" [the code still has bugs] afterward even if the finally isn't included).
<charleshi...@earthlink.net> wrote:
> I read that that would happen, but " print (sys.exc_info()[:2]) " didn't
> even yield a blank line. It must have executed, because the print statement
> on the line before it executed, and there wasn't a loop or a jump (and also
> execution continued "normally" [the code still has bugs] afterward even if
> the finally isn't included).
Unless it threw an exception, such as NameError if you haven't
imported sys. In that case, execution will continue through the
'finally' clause and then raise the exception (at least, I think
that's how it goes - raising exceptions in exception handlers is not
something I've made a study of).
(You posted privately to me again; I hope you don't mind my responding
on-list as this appears to have been merely oversight.)
On Wed, Jun 27, 2012 at 5:25 AM, Charles Hixson
<charleshi...@earthlink.net> wrote:
> Only thing is, this whole mess started when I was trying to trace down and
> expected error. (Which turned out to be "self.chunkLine(..." where self
> wasn't defined.) It was running without ANY error being displayed. Though
> as I look an outer loop is inclosed in a try:except:finally: It still has
> an unlabelled except, because I don't remember what exception is thrown when
> a file reads an unintelligible character (i.e., it isn't really a utf-8
> file). Currently I've fixed all the files so that they're either utf-8 or
> just ASCII, so currently it isn't getting triggered, but it's still there.
> So that's probably the explanation. I think I'll fix that now. (I can, I
> guess, assume that any exception will be caught by except BasicException:)
That's the problem, your blanket try/except. Don't do it! It blinds
you. Same goes for catching Exception or BaseException. Catch what you
really need to catch, and reserve catch-all statements for special
cases where you don't have access to the console.
> (You posted privately to me again; I hope you don't mind my responding
> on-list as this appears to have been merely oversight.)
> On Wed, Jun 27, 2012 at 5:25 AM, Charles Hixson
> <charleshi...@earthlink.net> wrote:
>> Only thing is, this whole mess started when I was trying to trace down and
>> expected error. (Which turned out to be "self.chunkLine(..." where self
>> wasn't defined.) It was running without ANY error being displayed. Though
>> as I look an outer loop is inclosed in a try:except:finally: It still has
>> an unlabelled except, because I don't remember what exception is thrown when
>> a file reads an unintelligible character (i.e., it isn't really a utf-8
>> file). Currently I've fixed all the files so that they're either utf-8 or
>> just ASCII, so currently it isn't getting triggered, but it's still there.
>> So that's probably the explanation. I think I'll fix that now. (I can, I
>> guess, assume that any exception will be caught by except BasicException:)
> That's the problem, your blanket try/except. Don't do it! It blinds
> you. Same goes for catching Exception or BaseException. Catch what you
> really need to catch, and reserve catch-all statements for special
> cases where you don't have access to the console.
If you can't remember what exception is raised, just try raising it deliberately.
Python _can_ be used interactively, after all. Even a short script to
test it won't take you very long!
> On Sun, 24 Jun 2012 16:16:25 -0700, Charles Hixson wrote:
>> But what I wanted was to catch any exception.
> Be careful of what you ask for, since you might get it.
> "Catch any exception" is almost certainly the wrong thing to do, almost
> always. The one good reason I've seen for a bare except is to wrap the
> top level of an application in order to redirect uncaught exceptions to
> something other than the console (such as a GUI error dialog box). And
> even then, you probably don't want to catch *all* exceptions, but only
> those that inherit from Exception:
> try:
> main() # run my application
> except Exception as err:
> display_error_dialog(err)
> # or log to a file, or something...
This time it was the right thing, as I suspected that *SOME* exception was being thrown, but had no idea what one. The problem was I didn't know how to print the result when I caught the exception. This has since been cleared up, but first I found it on Google, and then I was told about it on the list. The documentation left me totally ... well, not uninformed, but confused. As I said it turned out to be a method call on an uninitialized variable, as I found out once I figured out how to list the result of catching the exception. Which is what I expected the documentation to show me how to do.
The comments on the list have been vastly helpful, even if they still tend to assume that I know more than I do. (And even if some of them seem to be a bit ... off. E.g., suggesting that I generate the exception on purpose so I can find out what it is, when I started off with no idea as to WHAT the problem was.)
What really annoys me is the way the documentation has worsened since python 2.5, but if you know what it is trying to tell you, then I guess you aren't bothered by undefined terms and lack of examples. I went away from programming in Python for a couple of years though, and I guess I missed the transition, or something.
On Jun 28, 10:13 am, Charles Hixson <charleshi...@earthlink.net>
wrote:
> On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
> > "Catch any exception" is almost certainly the wrong thing to do, almost
> > always.
> This time it was the right thing, as I suspected that *SOME* exception
> was being thrown, but had no idea what one. The problem was I didn't
> know how to print the result when I caught the exception.
I think you're still missing the point. If you _didn't_ have a bare
try/except, the exception _would have been raised_ and the exception
displayed.
You _don't_ need an exception handler for exceptions to occur, they
just occur. You _only_ need a handler when you want to, y'know, handle
them.
> This has
> since been cleared up, but first I found it on Google, and then I was
> told about it on the list. The documentation left me totally ... well,
> not uninformed, but confused. As I said it turned out to be a method
> call on an uninitialized variable, as I found out once I figured out how
> to list the result of catching the exception. Which is what I expected
> the documentation to show me how to do.
The documentation doesn't expect you to write code to block error
reporting. If you had just removed the try/except, you would have seen
the problem right away.
> What really annoys me is the way the documentation has worsened since
> python 2.5, but if you know what it is trying to tell you, then I guess
> you aren't bothered by undefined terms and lack of examples. I went
> away from programming in Python for a couple of years though, and I
> guess I missed the transition, or something.
Can I suggest re-looking at the tutorial for errors & exceptions? I
really think you're making this a lot more difficult for yourself than
it needs to be.
On Wed, 27 Jun 2012 17:13:00 -0700, Charles Hixson wrote:
> On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
>> On Sun, 24 Jun 2012 16:16:25 -0700, Charles Hixson wrote:
>>> But what I wanted was to catch any exception.
>> Be careful of what you ask for, since you might get it.
>> "Catch any exception" is almost certainly the wrong thing to do, almost
>> always. The one good reason I've seen for a bare except is to wrap the
>> top level of an application in order to redirect uncaught exceptions to
>> something other than the console (such as a GUI error dialog box). And
>> even then, you probably don't want to catch *all* exceptions, but only
>> those that inherit from Exception:
>> try:
>> main() # run my application
>> except Exception as err:
>> display_error_dialog(err)
>> # or log to a file, or something...
> This time it was the right thing, as I suspected that *SOME* exception
> was being thrown, but had no idea what one. The problem was I didn't
> know how to print the result when I caught the exception.
> [...] once I figured out how
> to list the result of catching the exception.
If you had simply NOT caught it, the full traceback would have been printed automatically and you could have easily seen what exception was being raised, the error message, and where it was being raised from.
This is exactly why you should not have used a bare except, or any except at all, but just let the uncaught exception print on its own. When trying to diagnose bugs, try...except is not your friend. Tracebacks are your friend.
[...]
> What really annoys me is the way the documentation has worsened since
> python 2.5, but if you know what it is trying to tell you, then I guess
> you aren't bothered by undefined terms and lack of examples. I went
> away from programming in Python for a couple of years though, and I
> guess I missed the transition, or something.
If you have concrete examples of where you think the documentation could be improved, please either raise an enhancement request or bug report:
Charles Hixson wrote:
> On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
>> "Catch any exception" is almost certainly the wrong thing to do, almost
>> always.
> This time it was the right thing
No, it wasn't. If you hadn't caught it, Python would have printed it out for you, along with the full trace-back, giving you most if not all the information you needed to track down the bug.
