Re-raising exceptions with modified message

[Christoph Zwerschke]

What is the best way to re-raise any exception with a message
supplemented with additional information (e.g. line number in a
template)? Let's say for simplicity I just want to add "sorry" to every
exception message. My naive solution was this:

try:
...
except Exception, e:
raise e.__class__, str(e) + ", sorry!"

This works pretty well for most exceptions, e.g.

>>try:

.... 1/0
.... except Exception, e:
.... raise e.__class__, str(e) + ", sorry!"
....
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
ZeroDivisionErr or: integer division or modulo by zero, sorry!

But it fails for some exceptions that cannot be instantiated with a
single string argument, like UnicodeDecodeEr ror which gets "converted"
to a TypeError:

>>try:

.... unicode('\xe4')
.... except Exception, e:
.... raise e.__class__, str(e) + ", sorry!"
....
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
TypeError: function takes exactly 5 arguments (1 given)

Another approach is using a wrapper Extension class:

class SorryEx(Excepti on):
def __init__(self, e):
self._e = e
def __getattr__(sel f, name):
return getattr(self._e , name)
def __str__(self):
return str(self._e) + ", sorry!"

try:
unicode('\xe4')
except Exception, e:
raise SorryEx(e)

But then I get the name of the wrapper class in the message:

__main__.SorryE x: 'ascii' codec can't decode byte 0xe4 in position 0:
ordinal not in range(128), sorry!

Yet another approach would be to replace the __str__ method of e, but
this does not work for new style Exceptions (Python 2.5).

Any suggestions?

-- Chris

[Alex Popescu]

On Jul 6, 4:20 am, Christoph Zwerschke <[e-mail] wrote:

Alex Popescu wrote:

Probably the simplest solution would be to create a new exception and
wrapping the old one and the additional info. Unfortunately, this
may have a huge impact on 3rd party code that was catching the
original exception. So, I think you should create an utility
factory-like function that is either creating a new exception
instance as the one caught and with the additional information,

Right, I have gone with that (see the example with the PoliteException
class somewhere below).

or an utility that knows how to modify the caught exception according
to its type.

I guess you mean something like this (simplified):

except Exception, e:
if getattr(e, 'reason'):
e.reason += "sorry"
else:
e.message += "sorry"

The problem is that these attribute names are not standardized and can
change between Python versions. Not even "args" is sure, and if a class
has "message" it does not mean that it is displayed. Therefore I think
the first approach is better.

In the first case you will need somehow to tell to the new instance
exception the real stack trace, because by simply raising
a new one the original stack trace may get lost.

Yes, but thats a different problem that is easy to solve.

Yeah maybe for a python guy, but I am a newbie. I would really
appreciate if you can show in this thread how this can be done in
Python.

tia,

../alex
--
..w( the_mindstorm )p.

PS: sorry for reposting, but it looks like my previous message hasn't
gone through :-(.

[Neil Cerutti]

On 2007-07-06, Alex Popescu <th************ ***********@gma il.comwrote:

On Jul 6, 4:20 am, Christoph Zwerschke <[e-mail] wrote:

>Alex Popescu wrote:

Probably the simplest solution would be to create a new exception and
wrapping the old one and the additional info. Unfortunately, this
may have a huge impact on 3rd party code that was catching the
original exception. So, I think you should create an utility
factory-like function that is either creating a new exception
instance as the one caught and with the additional information,

Right, I have gone with that (see the example with the PoliteException
class somewhere below).

or an utility that knows how to modify the caught exception according
to its type.

I guess you mean something like this (simplified):

except Exception, e:
if getattr(e, 'reason'):
e.reason += "sorry"
else:
e.message += "sorry"

The problem is that these attribute names are not standardized and can
change between Python versions. Not even "args" is sure, and if a class
has "message" it does not mean that it is displayed. Therefore I think
the first approach is better.

In the first case you will need somehow to tell to the new instance
exception the real stack trace, because by simply raising
a new one the original stack trace may get lost.

Yes, but thats a different problem that is easy to solve.

Yeah maybe for a python guy, but I am a newbie. I would really
appreciate if you can show in this thread how this can be done
in Python.

Chech out the docs for sys.exc_info(), and for the raise
statement.

When handling an exception, you can rethrow a different
exception, but with the same traceback, by using the three-arg
version of raise.

See one of my earlier posts in this thread for a working example
(although it didn't solve Chris's problem).

--
Neil Cerutti

[Gerard Flanagan]

On Jul 6, 12:18 am, Christoph Zwerschke <[e-mail] wrote:

Sorry for the soliloquy, but what I am really using is the following so
that the re-raised excpetion has the same type:

def PoliteException (e):
class PoliteException (e.__class__):
def __init__(self, e):
self._e = e
def __getattr__(sel f, name):
return getattr(self._e , name)
def __str__(self):
if isinstance(self ._e, PoliteException ):
return str(self._e)
else:
return '\n%s: %s, I am sorry!' % (
self._e.__class __.__name__, str(self._e))
return PoliteException (e)

try:
unicode('\xe4')
except Exception, e:
raise PoliteException (e)

Would a decorator work here?
class PoliteException (Exception):
def __init__(self, e):
self._e = e
def __getattr__(sel f, name):
return getattr(self._e , name)
def __str__(self):
return '\n%s: %s, I am sorry!' % (
self._e.__class __.__name__, str(self._e))

def politefail(fn):
def wrapper(*args, **kwargs):
try:
return fn(*args, **kwargs)
except Exception, e:
raise PoliteException (e)
return wrapper

@politefail
def funktion():
unicode('\xe4')

funktion()

@politefail
def raise_exception (err, *args):
raise err(*args)
def funktion():
if 1 != 2:
raise_exception (ArithmeticErro r, '1 is not equal to 2.')

print
funktion()

[Christoph Zwerschke]

Gerard Flanagan wrote:

Would a decorator work here?

Depends on how you want to use that functionality. In my use case I only
need to catch the excpetion once.

Note that in your code the exception has not the right type which is
what I targeted in my last posting. I.e. the following will raise an
Exception if function is decorated:

try:
print funktion()
except ArithmeticError :
pass

-- Chris

[samwyse]

On Jul 5, 8:53 am, Christoph Zwerschke <[e-mail] wrote:

What is the best way to re-raise any exception with a message
supplemented with additional information (e.g. line number in a
template)? Let's say for simplicity I just want to add "sorry" to every
exception message. My naive solution was this:

try:
...
except Exception, e:
raise e.__class__, str(e) + ", sorry!"

This works pretty well for most exceptions, e.g.

>>try:

... 1/0
... except Exception, e:
... raise e.__class__, str(e) + ", sorry!"
...
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
ZeroDivisionErr or: integer division or modulo by zero, sorry!

But it fails for some exceptions that cannot be instantiated with a
single string argument, like UnicodeDecodeEr ror which gets "converted"
to a TypeError:

>>try:

... unicode('\xe4')
... except Exception, e:
... raise e.__class__, str(e) + ", sorry!"
...
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
TypeError: function takes exactly 5 arguments (1 given)

Another approach is using a wrapper Extension class:

class SorryEx(Excepti on):
def __init__(self, e):
self._e = e
def __getattr__(sel f, name):
return getattr(self._e , name)
def __str__(self):
return str(self._e) + ", sorry!"

try:
unicode('\xe4')
except Exception, e:
raise SorryEx(e)

But then I get the name of the wrapper class in the message:

__main__.SorryE x: 'ascii' codec can't decode byte 0xe4 in position 0:
ordinal not in range(128), sorry!

Yet another approach would be to replace the __str__ method of e, but
this does not work for new style Exceptions (Python 2.5).

Any suggestions?

-- Chris

Can "try" statements be used in "except" clauses? It appears so, thus
a hybrid approach might work well enough.

try:
...
except Exception, e:
try:
raise e.__class__, str(e) + ", sorry!"
except TypeError:
raise SorryEx(e)

That leaves the issue of the name being changed for
UnicodeDecodeEr ror, which might be fixable by diddling with __name__
properties. Or perhaps SorryEx needs to be a factory that returns
exception classes; the last line would be "SorryEx(e) ()". I'll have
to play with this a bit.

[samwyse]

On Jul 7, 4:13 pm, samwyse <samw...@gmail. comwrote:

On Jul 5, 8:53 am, Christoph Zwerschke <[e-mail] wrote:

What is the best way to re-raise any exception with a message
supplemented with additional information (e.g. line number in a
template)?

[...]

That leaves the issue of the name being changed for
UnicodeDecodeEr ror, which might be fixable by diddling with __name__
properties. Or perhaps SorryEx needs to be a factory that returns
exception classes; the last line would be "SorryEx(e) ()". I'll have
to play with this a bit.

OK, the following mostly works. You probably want the factory to copy
more of the original class into the SorryEx class each time, since
someone catching an exception may expect to look at things besides its
string representation.

def SorryFactory(e) :
class SorryEx(Excepti on):
def __init__(self):
self._e = e
def __getattr__(sel f, name):
return getattr(self._e , name)
def __str__(self):
return str(self._e) + ", sorry!"
SorryEx.__name_ _ = e.__class__.__n ame__
return SorryEx

def test(code):
try:
code()
except Exception, e:
try:
raise e.__class__, str(e) + ", sorry!"
except TypeError:
raise SorryFactory(e) ()

test(lambda: unicode('\xe4') )

[Christoph Zwerschke]

Did you run this?
With Py < 2.5 I get a syntax error, and with Py 2.5 I get:

new.__class__ = old.__class__
TypeError: __class__ must be set to a class

-- Chris

[Christoph Zwerschke]

samwyse wrote:

def test(code):
try:
code()
except Exception, e:
try:
raise e.__class__, str(e) + ", sorry!"
except TypeError:
raise SorryFactory(e) ()

Ok, you're suggestig the naive approach if it works and the factory
approach I came up with last as a fallback. Maybe a suitable compromize.

-- Chris

[samwyse]

On Jul 12, 6:31 am, samwyse <samw...@gmail. comwrote:

On Jul 8, 8:50 am, Christoph Zwerschke <[e-mail] wrote:

With Py 2.5 I get:

new.__class__ = old.__class__
TypeError: __class__ must be set to a class

Hmmm, under Python 2.4.X, printing repr(old.__clas s__) gives me this:
<class exceptions.Unic odeDecodeError at 0x00A24F00>
while under 2.5.X, I get this:
<type 'exceptions.Uni codeDecodeError '>
So, let's try sub-classing the type:

def modify_message( old, f):
class Empty: pass
new = Empty()
print "old.__clas s__ =", repr(old.__clas s__)
print "Empty =", repr(Empty)
new.__class__ = Empty

class Excpt(old.__cla ss__): pass
print "Excpt =", repr(Excpt)
print "Excpt.__class_ _ =", repr(Excpt.__cl ass__)
new.__class__ = Excpt

new.__dict__ = old.__dict__.co py()
new.__str__ = f
return new

Nope, that gives us the same message:

old.__class__ = <type 'exceptions.Uni codeDecodeError '>
Empty = <class __main__.Empty at 0x00AB0AB0>
Excpt = <class '__main__.Excpt '>
Excpt.__class__ = <type 'type'>
Traceback (most recent call last):
[...]
TypeError: __class__ must be set to a class

Excpt ceratinly appears to be a class. Does anyone smarter than me
know what's going on here?

[Christoph Zwerschke]

samwyse wrote:

TypeError: __class__ must be set to a class

Excpt ceratinly appears to be a class. Does anyone smarter than me
know what's going on here?

Not that I want to appear smarter, but I think the problem here is that
exceptions are new-style classes now, whereas Empty is an old-style
class. But even if you define Empty as a new-style class, it will not
work, you get:

TypeError: __class__ assignment: only for heap types

This tells us that we cannot change the attributes of a built-in
exception. If it would be possible, I simply would have overridden the
__str__ method of the original exception in the first place.

-- Chris