This project is archived and is in readonly mode.
"pgcode" should be present in exception.args
Reported by Piotr Czachur | January 27th, 2012 @ 10:31 AM
Now only exception message is present in exception.args.
It would be handy if pgcode was passed to Psycopg2 exception constructor, so it would be available in exception.args - it is the purpose of agrs property to store such information.
Comments and changes to this ticket
- State changed from new to hold
If we put stuff in args, it ends up being printed everywhere, changing the current behaviour of the exception:
In : class MyException(Exception): pass ...: In : try: raise MyException('foo', 10, 20) ...: except MyException, e: pass ...: In : e Out: MyException('foo', 10, 20) In : print e ('foo', 10, 20)
We also have three independent attributes for exceptions: pgerror, pgcode and cursor, and the second is mostly independent from the first two, which makes positional arguments an awkward implementation.
It's also more explicit to access exc.pgerror than exc.args.
What would be the advantages in using args? Would they outweigh these drawbacks?
* When you log exception, you see also pgcode, which may be important (error messages can change, while pgcode should remain unchanged (user's stored functions))
* What's wrong that pgcode is being printed everywhere? * I agre that accessing e.args is not so friendly, but you can always provide getter function.
Please decide yourself... it's really not important issue.
The pgcode may be important, but I suspect now it would mostly break other people code (only at visualization level, but knowing from the past I'd say it would be enough to piss people).
My decision would be not to change the exception. However, please feel entirely free to raise the question to the mailing list and see what would be ok for other users. If there is a good use case to have the pgcode in the args, or in the str(), which I suspect is what you are really after, I would have no problem in changing the code.
After some thoughts, I agree that enhancment it would provide would be supressed by backward incompatibilitiy issues, so leaving it as it is, is the best choice for now.
If I find some more solid motivation for this change I will put on the mailing list.
Thank you very much for great attitude.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<b>WARNING:</b> the informations in this tracker are archived. Please submit new tickets or comments to <a href="https://github.com/psycopg/psycopg2/issues">the new tracker</a>.
Psycopg is the most used PostgreSQL adapter for the Python programming language. At the core it fully implements the Python DB API 2.0 specifications. Several extensions allow access to many of the features offered by PostgreSQL.