Opened 7 years ago

Closed 7 years ago

#9455 closed (fixed)

Undefined local `error` in the LaxOptionParser._process_args method

Reported by: egenix_viktor Owned by: nobody
Component: Core (Other) Version: 1.0
Severity: Keywords: LaxOptionParser _process_args undefined local error
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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/ 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...

Change History (6)

comment:1 Changed 7 years ago by egenix_viktor

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Some debug info to help reproducing it:

OS: Ubuntu Linux 7.10, but it should be indifferent


NameError: global name 'error' is not defined

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

Variable values at the place of exception:

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

>>> arg

>>> 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.

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by mtredinnick

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.

comment:4 Changed 7 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in r9470.

comment:5 Changed 7 years ago by baus

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:6 Changed 7 years ago by baus

  • Resolution set to fixed
  • Status changed from reopened to closed

I apologize. I see this is fixed in trunk.

Note: See TracTickets for help on using tickets.
Back to Top