How to catch str exception?

[anurag...@yahoo.com]

import sys
try:
raise "xxx"
except str,e:
print "1",e # is not caught here
except:# is caught here
print "2",sys.exc_type,sys.exc_value

In the above code a string exception is raised which though deprecated
but still a 3rd party library I use uses it. So how can I catch such
exception without relying on catch all, which could be bad.

system: Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3
(Ubuntu 4.2.3-2ubuntu7)] on linux2

[Kurt Symanzik]

"anurag...@yahoo.com" <anurag...@yahoo.com> wrote on 2009-05-15
4:13:15 PM +0800

Try this, i.e. catch the exact string:

except "xxx":

Kurt

--
Kurt Symanzik
ku...@kbsymanzik.org
Skype id: ksymanzik
http://kbsymanzik.org

[anurag...@yahoo.com]

but the whole point of catching such exception is that i can print its
value
there are many such exceptions and hence it is not feasible to catch
them all or know them all unless i go thru src code.

[Peter Otten]

anurag...@yahoo.com wrote:

Catch them all with a bare except and then reraise non-string exceptions:

try:
raise "abc"
except:
e, t, tb = sys.exc_info()
if not isinstance(e, str):
raise
print "caught", e

[anurag...@yahoo.com]

> try:
>     raise "abc"
> except:
>     e, t, tb = sys.exc_info()
>     if not isinstance(e, str):
>         raise
>     print "caught", e

This seems to be the solution, thanks

[Dave Angel]

Just fix the except type to be the exception caused by the illegal "raise"

except TypeError,e:
print "1",e # is caught here

1 exceptions must be classes or instances, not str

[anurag...@yahoo.com]

> except TypeError,e:
>     print "1",e # is caught here
>
> 1 exceptions must be classes or instances, not str

doesn't happen so in 2.5.2

[MRAB]

If string exceptions are so difficult to use, don't use them! :-)

It would be better to write your own exception class:

class MyException(Exception):
pass

try:
raise MyException("Something bad happened!")
except MyException, e:
print "ERROR: %s" % e

[anurag...@yahoo.com]

> It would be better to write your own exception class:
>
> class MyException(Exception):
>      pass

and how would i automatically inject this into 3rd part library

[MRAB]

Ah, I wasn't reading carefully enough! :-)

[Dave Angel]

I tested it in 2.6.2

Perhaps you could try something like:

try:
raise "xxx"
except Exception, e:

print "1",e # is caught here

...and then test e.message and reraise if necessary

[Terry Reedy]

I think you have discovered why they are gone in Py3 ;-).

[Paul Rubin]

"anurag...@yahoo.com" <anurag...@yahoo.com> writes:
> there are many such exceptions and hence it is not feasible to catch
> them all or know them all unless i go thru src code.

But that is true of all exceptions. The alternative seems to be a
"checked exception" scheme like Java's, which in practice imposes a
huge pain on programmers, who have to modify type signatures all up
and down the call hierarchy every time they raise another exception at
the bottom level.

[MRAB]

I would've thought that a modern IDE would do a lot of the work for you.

[Rhodri James]

Do be aware that string exceptions are going away, so at
some point you're going to upgrade your version of Python
and your scripts will mysteriously stop working. Peter's
patch will help you for now, but it's a double-edged sword
in that it also lets you pretend that you don't have to
fix the problem properly later. In my experience it's
generally best to fix the problem now rather than paper
over the cracks.

Since this is a third-party library doing this, as far as
I can see it you have three choices:

1) Get hold of a more up-to-date version of the module,
if there is one.

2) Ask the module writers nicely to fix the problem.

3) Fix it yourself.

The beauty of Python is that 3) isn't all that hard!

--
Rhodri James *-* Wildebeeste Herder to the Masses

[Cameron Simpson]

I used to think that too, but it's not entirely true.

Aside: I loved the discipline that comes with Java's interface strictness
but found the language felt cumbersome; Python's duck typing approach
is far simpler to work with but lets you be a lot sloppier because many
implementation shortcomings will only show at runtime, whereas Java's
rigidity can be used to catch a lot of stuff at compile time.

Anyway, to the exception thing: if you're throwing a "new" type of
exception then either you've changes the object model and Java rightly
complains, if you're breaking the object encapsulation and you should
be catching the new exceptions fairly low down and either handling it or
raising a "conformant" exception the caller expected. This isually happens
across a type boundary; for example a data structure that just happens to
use an SQL db for backing structure should be catching any SQL exceptions
and recasting them to an appropriate outer exception for the user,
probably inserting the underlying SQL exception into the new exception
as an attribute.

Anyway, my basic point here is that the asserting that your have to

"modify type signatures all up and down the call hierarchy every time they

raise another exception" should have a fairly limited scope. Unexpected
exceptions _shouldn't_ be happening. We routinely write stuff like:

try:
n = int(foo)
except ValueError, e:
print >>sys.stderr, "not an integer: %s" % foo

If int() starts throwing non-ValueError exceptions then many many
programs break. Java would prevent one from changing int() in such
a fashion outright. Python requires the self-discipline on the part of
the implementer of int() to raise only ValueError exceptions, and
internally handle anything else at a lower level.

Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Widget. It's got a widget. A lovely widget. A widget it has got.
- Jack Dee