development server stops on SyntaxError or other Exceptions

[eibaan]

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.

[Malcolm Tredinnick]

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.

[anonymous]

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.

[eibaan]

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.

[Glenn Maynard]

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.

[Glenn Maynard]

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

[Karen Tracey]

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

[berto]

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.

[berto]

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

[berto]

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

[Jacob]

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

[Glenn Maynard]

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

[Glenn Maynard]

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.

[Glenn Maynard]

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.

[Aymeric Augustin]

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

[Ramiro Morales <cramm0@…>]

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.

[Aymeric Augustin <aymeric.augustin@…>]

In bbabfdcccee9ccd98fc140233dee748253bcb4a2:

Fixed #19485 -- Python 3 compatibility for c2a6b2a4.

Refs #9589.