Undefined local `error` in the LaxOptionParser._process_args method

[egenix_viktor]

Django 1.0, release version

I encountered an undefined local variable in Django itself while porting an application to Django 1.0:

In core/management/init.py there is a LaxOptionParser._process_args method. It can raise an exception the following way:

raise error

It is under while / try / if-else. Line 210 in Django 1.0 release version. The error local is undefined here.

The else clause is reached due to a wrong command line parameter, probably. I'm going to track it down...

[egenix_viktor]

Some debug info to help reproducing it:

OS: Ubuntu Linux 7.10, but it should be indifferent

Exception:

NameError: global name 'error' is not defined

File "/my_app_dir/manage.py", line 11, in <module>
  execute_manager(settings)
File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 340, in execute_manager
  utility.execute()
File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 268, in execute
  options, args = parser.parse_args(self.argv)
File "/usr/lib/python2.5/optparse.py", line 1378, in parse_args
  stop = self._process_args(largs, rargs, values)
File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 210, in _process_args
  raise error

Variable values at the place of exception:

>>> sys.argv
['/my_app_dir/manage.py', 'runserver', '--noreload']

>>> arg
'/my_app_dir/manage.py'

>>> rargs
['runserver', '--noreload']

NOTE: I tried to run my app under Wing IDE with the usual settings worked for 0.96. I'm sure I made a mistake. The problem here is not the wrong command line, but the undefined error variable causing a misleading exception.

[egenix_viktor]

It seems to me, that the application works, actually. It seems to handle the NameError exception, then starts as expected. So this problem turns into a new question:

• Why does Django use such an exception for its normal execution flow?

It seems to be a design flaw for me. Or I might not aware of something important about Django...

Thanks for your comments in advance.

[Malcolm Tredinnick]

You don't provide any way to repeat the problem -- the command line implied by your debug information works correctl, so that's not it. Due to the surrounding try...except, the existing code actually has the right effect (it makes it into the except block, which catches everything), even if only by accident. I'll change it to make code linting tools happy, but it's not really a bug.

[Malcolm Tredinnick]

Fixed in r9470.

[baus]

This problem still exists in 1.0.2. The coded raise is never executed because NameError is raised before "raise error" is executed. The except actually handles the NameError not the undefined "error".

WingIDE catches this problem because the debugger stops on all NameError exceptions by default.

I believe changing raise error to raise Exception() provides the desired behavior.

[baus]

I apologize. I see this is fixed in trunk.