Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #24406 > unrolled thread

Re: exception problem

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: exception problem Charles Hixson <charleshixsn@earthlink.net> - 2012-06-24 16:16 -0700
    Re: exception problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-25 07:48 +0000
      Re: exception problem Charles Hixson <charleshixsn@earthlink.net> - 2012-06-27 17:13 -0700
        Re: exception problem alex23 <wuwei23@gmail.com> - 2012-06-27 17:36 -0700
        Re: exception problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-28 03:44 +0000
      Re: exception problem Ethan Furman <ethan@stoneleaf.us> - 2012-06-28 05:52 -0700

#24406 — Re: exception problem

On 06/24/2012 03:43 PM, MRAB wrote:
> 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.)

-- 
Charles Hixson

[toc] | [next] | [standalone]

#24419

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...



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#24565

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.  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.

-- 
Charles Hixson

[toc] | [prev] | [next] | [standalone]

#24569

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.

http://docs.python.org/tutorial/errors.html

[toc] | [prev] | [next] | [standalone]

#24581

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:

http://bugs.python.org/

or at least raise them here (and hope somebody else raised the bug 
report).

Otherwise, there's nothing we can do about vague complaints.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#24610

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.

~Ethan~

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web