
Sorry if this message is not a direct reply to Ka-Ping Yee message on PEP344, I'm in vacation in China and there's a thing I must say that could make sense in PEP344. I do a lot of exception re-raising at work; I use that technique to add content to exception messages while keeping the original stack. I even created a reraise function that I use that way: try: parser.parseFile(file) exeption Exception, exception: reraise(exception, "Error at line %s in file %s" % (x,y)) (x,y) are details, but you get the idea. This very useful in many situations. In the example, it works when an error is happening in parsing a file including other files (like xml files with <xs:include>). That way you get the exact path of inclusion leading to the error. It is also useful when an error happen in very generic code and when traceback is not enough to know which element was causing the error. What I propose is that all exceptions objects have a standard way to add additional informations. Something like: try: foo() except Exception, exception: exception.add_info("some info") raise exception from (whatever the proposition is) You might ask, "why not just reraise a new exception?". It is more useful to reraise the same exception type, making it possible to use selective except clauses and (avoid problems with code using them like hasattr). I think what would be simpler is not affect __str__ representation and prepend to a list the additional infos inside the exception object, adding a function to get these infos. I don't mind how it would be done in fact, as long as the need is fulfilled. I won't be able to read my messages often for the next 10 days, but I hope others will see the point I try to bring;) Regards, Nicolas Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html