Re: [PATCH v2 10/20] git-remote-testgit: fix error handling
- From
Sverre Rabbelier <srabbelier@gmail.com>
- Date
- Jun 20, 2011, 18:02 UTC
- Message-ID
- <BANLkTimW8paPUHoYLpB_diY_s0L4aQCcgQ@mail.gmail.com>
- In-Reply-To
- <jfzVoEhsVKgfY8Vp692jfTk1lNp2lhg9JCJc8MiY6N6th3PzBJoHzw@cipher.nrlssc.navy.mil>
Heya,
On Mon, Jun 20, 2011 at 19:50, Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> wrote:
Show 7 quoted lines
> Well, I don't see anywhere where CalledProccessError is actually caught. > i.e. I don't see > > except subprocess.CalledProcessError: > > anywhere. So, on python 2.5+ if this exception is ever raised, the > script would just exit and produce a backtrace right?
We're not trying to catch it, but we raise it (since that's what the python 2.5 implementation of check_call does). But if it's not defined in python 2.4, then my patch broke 2.4 again :).
Show 6 quoted lines
> On python 2.4, it would also exit and produce a backtrace that > looks like this: > > File "test.py", line 11, in check_call > raise subprocess.CalledProcessError(retcode, cmd) > AttributeError: 'module' object has no attribute 'CalledProcessError'
Yeah, it would, my bad :(. I'll just define a dummy CalledProcessError if it isn't defined to support python 2.4
Show 5 quoted lines
> Btw. the only reason I submitted those changes to support python 2.4 > was because RHEL 5.X ships with python 2.4, and the changes were not > too intrusive. So, it should be considered whether supporting 2.4 > is desirable. I wouldn't want to increase the maintenance burden > on the real python developers (i.e. not me).
Wikipedia says RHEL 5.x will ready End of Production 1 on Q4 2011, but RHEL 6.x has been out only a little over half a year, so it's probably worth doing.
-- Cheers, Sverre Rabbelier