Opened 15 years ago

Closed 12 years ago

Last modified 11 years ago

#9589 closed Bug (fixed)

development server stops on SyntaxError or other Exceptions

Reported by: eibaan Owned by: nobody
Component: Core (Management commands) Version: 1.1
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

It's a bit annoying that you have to manually restart the development server if you have a
SyntaxError, ImportError or NameError in a file because changes to that file are not detected.

This is caused - I think - by the fact that the autoreloader only watches files of successfully loaded modules.

I created a patch that catches those errors and adds fake modules to the system so that the autoreloader also checks for changes in those files. It's kind of hackish but it causes the reload after fixing the problems as wished for.

Attachments (3)

autoreload-r9410.patch (1.6 KB ) - added by eibaan 15 years ago.
autoreload.diff (2.7 KB ) - added by Glenn Maynard 15 years ago.
fixed 'exceptions.TypeError' object has no attribute 'filename'
autoreload-error_decorator-r11628.patch (2.2 KB ) - added by berto 14 years ago.
Added decorator that checks for file errors and adds them to watch list.

Download all attachments as: .zip

Change History (19)

by eibaan, 15 years ago

Attachment: autoreload-r9410.patch added

comment:1 by Malcolm Tredinnick, 15 years ago

Triage Stage: UnreviewedDesign decision needed

This looks like a cure that's worse than the disease. After installing this fake module, you're now no longer running the correct code, so all sorts of unexpected things could happen, which will be quite misleading.

Given that the current error handling, although possibly a little annoying from time to time, is very explicit and doesn't result in incorrect behaviour, I prefer the current stuff. -1 from me on this patch.

comment:2 by anonymous, 15 years ago

I'd rather see it stay how it is now, though error messages should make it clear that any "no reverse exception" errors might be caused by errors while importing views.

comment:3 by eibaan, 15 years ago

mtredinnick, please notice that after an exception, no code is (or should) actually running anymore. The system stopps responding and only the background thread looking for file changes is still active. This is how the system behaves for all other exceptions already. I just added support for SyntaxError and ImportError. Fixing those problems in files is not detected by the background thread right now. I tried to add them. Faking modules seemed to be the easiest way to do so. Because I do not use "real" module names, there shouldn't be any strange side effects.

anonymous, this hasn't to do with "no reverse exception". My patch fixes the problem that after you made a syntax error in some file, the development server breaks down and has to be restarted manually.

comment:4 by Glenn Maynard, 15 years ago

This problem is pretty annoying, but I think this fix is a bit too much of a hack. I don't think it'll actually cause problems, but the attached patch should be a bit cleaner. It needs testing with jython_reloader.

by Glenn Maynard, 15 years ago

Attachment: autoreload.diff added

fixed 'exceptions.TypeError' object has no attribute 'filename'

comment:5 by Karen Tracey, 14 years ago

#11957 reported problems in this area with errors in admin.py files specifically. Not sure whether that is covered by the change proposed here.

comment:6 by berto, 14 years ago

I've created a patch that uses a decorator to solve this problem. When main() is called to start the reloader, the function passed in is wrapped in a decorator that currently catches IndentationError, NameError, SyntaxError, or TypeError. When one these exceptions is found, the file that caused the error is added to a list of watched files. This list is checked for modifications in addition to the files found in sys.modules.

by berto, 14 years ago

Added decorator that checks for file errors and adds them to watch list.

comment:7 by berto, 14 years ago

I have updated patch autoreload-error_decorator-r11628.patch, which now handles ImportError as well.

comment:8 by Jacob, 14 years ago

Resolution: wontfix
Status: newclosed

I agree with Malcolm, so I'm marking this wontfix.

comment:9 by Glenn Maynard, 14 years ago

With who? This is very obviously a bug, and an annoying one. It makes no sense to wontfix this.

comment:10 by Glenn Maynard, 14 years ago

To respond more usefully (and less out of simple bewilderment), and assuming that "mtredinnick" is Malcolm (it would be helpful to not use names that make other people do research to follow a ticket; use the names being used in the tracker):

He responded to the initial patch, which had the bizarre behavior of modifying the global modules table (which should almost always be treated as read-only), and which nobody else liked either. That's why there are rewritten patches which eliminate that problem. I'm confused because you closed the bug agreeing that the first patch wasn't acceptable, despite the clean patches offered later by myself and berto.

comment:11 by Glenn Maynard, 14 years ago

Resolution: wontfix
Status: closedreopened
Version: 1.01.1

No response in over a month, and my inquiry on django-dev was ignored, so I'm reopening this. The reason for closing it made no sense. If you reclose it, please do those of us who have spent time fixing this the courtesy of giving a meaningful explanation, and not just pointing to a reason that's six months irrelevant which multiple other people have long since corrected.

comment:12 by Gabriel Hurley, 13 years ago

Component: django-admin.py runserverCore (Management commands)

comment:13 by Luke Plant, 13 years ago

Severity: Normal
Type: Bug

comment:14 by Aymeric Augustin, 12 years ago

Easy pickings: unset
Resolution: duplicate
Status: reopenedclosed
UI/UX: unset

This problem was first reported in #8413. That ticket has a patch with a different technique.

comment:15 by Ramiro Morales <cramm0@…>, 11 years ago

Resolution: duplicatefixed

In c2a6b2a43fb8f32cff078c823054e2e65f325464:

Fixed #9589 -- Made development web server more robust in the presence of a wider variety of code errors.

Thanks goes to contributor with Trac user 'berto' for the patch.

comment:16 by Aymeric Augustin <aymeric.augustin@…>, 11 years ago

In bbabfdcccee9ccd98fc140233dee748253bcb4a2:

Fixed #19485 -- Python 3 compatibility for c2a6b2a4.

Refs #9589.

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