On 03/30/2017 08:36 PM, Doug Hellmann wrote:
Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
On Tue, 2017-03-21 at 22:10 +0000, Taryma, Joanna wrote:
However, pep8 does not accept passing variable to translation
functions, so this results in ‘H701 Empty localization string’ error.
Possible options to handle that:
1) Duplicate messages:
LOG.error(“<error message>”, {<key>: <val>})
raise Exception(_(“<error message>”) % {<key>: <val>})
2) Ignore this error
3) Talk to hacking people about possible upgrade of this check
4) Pass translated text to LOG in such cases
I’d personally vote for 2. What are your thoughts?
When the translators go to translate, they generally only get to see
what's inside _(), so #2 is a no-go for translations, and #3 also is a
no-go.
--
I think the appropriate thing here is to do something like:
msg = _('<error message>') % {<key>: <val>}
LOG.error(msg)
raise Exception(msg)
This results in a translated string going to the log, but I think that's
OK.
Why is the error being logged and then thrown? If it's a true exception,
won't the outer-most part of the application loop log the error? And if
it's something that the application is catching and handling, that makes
it seem like it's not an operator-facing error.
This sounds nice, and we did it for some time. But it ends up being a
debugability nightmare, so now I usually -1 people for not having this
LOG.error. This is because every re-raise loses some valuable information;
crossing the RPC border probably loses even more. It is particularly bad, when
the error messages from innermost exceptions are not helpful (hello, KeyError).
My personal favorite case was something like:
"Failed to power off the node <UUID>. Unable to parse XML."
Getting something like that in ironic-api logs would probably not be too
helpful.
Doug
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
