forcing exceptions

[Nikola Skoric]

Is there a way to tell the interpreter to display exceptions, even those
which were captured with except?

--
"Now the storm has passed over me
I'm left to drift on a dead calm sea
And watch her forever through the cracks in the beams
Nailed across the doorways of the bedrooms of my dreams"

[Paul Rubin]

Re: forcing exceptions

Nikola Skoric <nick-news@net4u.hr> writes:[color=blue]
> Is there a way to tell the interpreter to display exceptions, even those
> which were captured with except?[/color]

Normally you wouldn't do that unless you were trying to debug the
interpreter itself. It uses caught exceptions for all sorts of things
that you probably don't want displayed. I think even ordinary loop
termination may be implemented using exceptions.

[Gary Herron]

Re: forcing exceptions

Nikola Skoric wrote:
[color=blue]
>Is there a way to tell the interpreter to display exceptions, even those
>which were captured with except?
>
>
>[/color]
Yes, sort of ... You have to trigger the display yourself within the
capturing "except" -- it's not automatic.

The traceback module provides a number of functions that can be used to
display a traceback of the current (or any other) exception. In
addition, it can produce a traceback of the current state of the
execution stack even without an exception:

Example (type this into the Python interpreter):

import traceback
try:
assert False
except:
traceback.print _exc()

and you'll get a traceback (a very short one in this case):

Traceback (most recent call last):
File "<stdin>", line 2, in ?
AssertionError

Gary Herron

[Nikola Skoric]

Re: forcing exceptions

In article <7xd5h3pas7.fsf @ruckus.brouhah a.com>, Paul Rubin
<http://phr.cx@NOSPAM.i nvalid> says...[color=blue]
> Nikola Skoric <nick-news@net4u.hr> writes:[color=green]
> > Is there a way to tell the interpreter to display exceptions, even those
> > which were captured with except?[/color]
>
> Normally you wouldn't do that unless you were trying to debug the
> interpreter itself. It uses caught exceptions for all sorts of things
> that you probably don't want displayed. I think even ordinary loop
> termination may be implemented using exceptions.[/color]

Yes, thanks for your quick responses, all three. You're right, I don't
want to debug python :-) But I figured out that I don't need captured
exceptions, the thing is that I just didn't belive the problem was that
obvious. In fact, problem was in the except block, not in it's try
block. The except block had this inocent statement:

print self.sect[1].encode('utf-8')

Which results in:

Traceback (most recent call last):
File "AIDbot2.py ", line 238, in ?
bot.checkNomina tions()
File "AIDbot2.py ", line 201, in checkNomination s
if sect.parseSect( ) == 1:
File "AIDbot2.py ", line 96, in parseSect
print self.sect[1].encode('utf-8')
UnicodeDecodeEr ror: 'ascii' codec can't decode byte 0xfc in position 15:
ordinal
not in range(128)

Now, who can it complain about 'ascii' when I said loud and clear I want
it to encode the string to 'utf-8'??? Damn unicode.

--
"Now the storm has passed over me
I'm left to drift on a dead calm sea
And watch her forever through the cracks in the beams
Nailed across the doorways of the bedrooms of my dreams"

[Peter Otten]

Re: forcing exceptions

Nikola Skoric wrote:
[color=blue]
> print self.sect[1].encode('utf-8')
>
> Which results in:
>
> Traceback (most recent call last):
> File "AIDbot2.py ", line 238, in ?
> bot.checkNomina tions()
> File "AIDbot2.py ", line 201, in checkNomination s
> if sect.parseSect( ) == 1:
> File "AIDbot2.py ", line 96, in parseSect
> print self.sect[1].encode('utf-8')
> UnicodeDecodeEr ror: 'ascii' codec can't decode byte 0xfc in position 15:
> ordinal
> not in range(128)
>
> Now, who can it complain about 'ascii' when I said loud and clear I want
> it to encode the string to 'utf-8'??? Damn unicode.[/color]

Trying to encode a str s results in something like

unicode(s, "ascii").encode ("utf-8")

where the first step, i. e. the conversion to unicode fails for non-ascii
strings. The solution is to make that conversion explicit and provide the
proper encoding. Assuming the initial string is in latin1:

unicode(self.se ct[1], "latin1").encod e("utf-8")

Of course, if you can ensure that self.sect[1] is a unicode instance earlier
in your code, that would be preferable.

Peter

[Robert Kern]

Re: forcing exceptions

Nikola Skoric wrote:
[color=blue]
> Traceback (most recent call last):
> File "AIDbot2.py ", line 238, in ?
> bot.checkNomina tions()
> File "AIDbot2.py ", line 201, in checkNomination s
> if sect.parseSect( ) == 1:
> File "AIDbot2.py ", line 96, in parseSect
> print self.sect[1].encode('utf-8')
> UnicodeDecodeEr ror: 'ascii' codec can't decode byte 0xfc in position 15:
> ordinal
> not in range(128)
>
> Now, who can it complain about 'ascii' when I said loud and clear I want
> it to encode the string to 'utf-8'??? Damn unicode.[/color]

Presumably, self.sect[1] is not a unicode string, but a regular string. The
utf-8 encoder only takes unicode strings, so it tries to convert the input into
a unicode string first. ASCII is the default encoding when no encoding is specified.

Standard practice with unicode is to only do conversions at the boundaries
between your code and interfaces that really need bytes (files, the console, the
network, etc.). Convert to unicode strings as soon you get the data and only
convert to regular strings when you have to. Everything *inside* your code
should be unicode strings, and you shouldn't try to pass around encoded regular
strings if at all possible, although pure ASCII strings generally work because
it is the default encoding.

So double-check self.sect[1] and figure out why it isn't a unicode string.

--
Robert Kern
robert.kern@gma il.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter