Записывать все ошибки в консоли или файл на сайте Джанго

Question

Записывать все ошибки в консоли или файл на сайте Джанго

голоса

13

Как я могу получить Django 1,0 писать все ошибки в консоли или файл журнала при запуске runserver в режиме отладки?

Я попытался с помощью класса промежуточного слоя с функцией process_exception, как описано в принятом ответ на этот вопрос:

Как вы журнал ошибок сервера на Джанго сайтов

Функция process_exception вызываются для некоторых исключений (например, утверждает (False) в views.py), но process_exception не вызывалось для других ошибок, как ImportErrors (например: импорт thisclassdoesnotexist в urs.py). Я новичок в Django / Python. Является ли это из-за некоторые различия между временем выполнения и во время компиляции ошибками? Но тогда я бы ожидать runserver жаловаться, если это была ошибка во время компиляции, и это не делает.

Я наблюдал за фантастическую презентацию Саймона Виллисон на отладке Django ( http://simonwillison.net/2008/May/22/debugging/ ) , но я не вижу вариант , который будет работать хорошо для меня.

В случае , если это уместно, я пишу приложение Facebook и Facebook маски HTTP 500 ошибок с их собственным сообщением , а не показывать грозно информативный 500 страницы Django. Так что я нужен способ для всех типов ошибок , которые будут записаны в консоль или файл.

Изменить: Я думаю , мое ожидание, что если Django может вернуть страницу 500 ошибок с большим количеством деталей , когда у меня плохой импорт (ImportError) в urls.py, он должен быть в состоянии написать ту же деталь на консоль или файл без чтобы добавить любую дополнительную обработку исключений в коде. Я никогда не видел обработки исключений вокруг операторов импорта.

Спасибо, Джефф

python django facebook

Задан 27/03/2009 в 18:30
источник пользователем jlpp

На других языках...

5 ответов

голоса

2

Во-первых, очень мало ошибок времени компиляции, что вы будете видеть через журнал исключений. Если ваш код Python не имеет допустимый синтаксис, он умрет задолго до того, открыты журналы для записи.

В режиме runserver Джанго, заявление «печать» пишет в стандартный вывод, который вы можете увидеть. Это не является хорошим долгосрочным решением, однако, так что не рассчитывайте на это.

Когда Django работает под Apache, однако, это зависит от того, какой плагин в вы используете. mod_python не так легко иметь дело. mod_wsgi может быть принужден к отправке стандартный вывод и стандартный поток ошибок в лог-файл.

Лучше всего, однако, является протоколирование модуль. Поместите инициализацию в верхний уровень , urls.pyчтобы настроить ведение журнала. (Или, может быть, ваш settings.py)

Убедитесь, что каждый модуль имеет регистратор доступный для записи сообщений журнала.

Убедитесь, что каждый веб-услуги призывают вас сделать есть попробовать / за исключением блока вокруг него, и вы пишете исключения из вашего журнала.

Ответил 27/03/2009 в 19:51
источник пользователем S.Lott

голоса

-1

Если вы на системе NIX * вы могли бы

запись в журнале (например. mylog.txt) в Python затем запустить «хвост -f mylog.txt» в консоли

это удобный способ просмотра любого типа журнала в режиме реального времени

Ответил 28/03/2009 в 23:03
источник пользователем

голоса

6

Функция process_exception вызываются для некоторых исключений (например, утверждает (False) в views.py), но process_exception не вызывалось для других ошибок, как ImportErrors (например: импорт thisclassdoesnotexist в urs.py). Я новичок в Django / Python. Является ли это из-за некоторые различия между временем выполнения и во время компиляции ошибками?

Нет, это просто потому , что process_exception промежуточного слоя вызывается только при возникновении исключения в представлении .

Я думаю , что DEBUG_PROPAGATE_EXCEPTIONS (как упомянуто первый Джейсон Бейкер) является то , что вам нужно, но я не думаю , что вам не нужно делать что - либо дополнительное (т.е. sys.excepthook, и т.д.) , если вы просто хотите отслеживающий сбрасывали в консоль.

Если вы хотите сделать что - нибудь более сложным с ошибкой (т.е. дамп в файл или базу данных), самый простой подход был бы сигнал got_request_exception , который Django посылает для любого запроса , связанных с исключением, был ли он поднят в представлении или нет.

В get_response и handle_uncaught_exception методы django.core.handlers.BaseHandler поучительны (и краткое) чтение в этой области.

без добавления каких-либо дополнительных обработки исключений в коде. Я никогда не видел обработки исключений вокруг операторов импорта.

Посмотрите вокруг немного больше, вы увидите, что это сделано (часто в тех случаях, когда требуется обработать отсутствие зависимости в каком-то определенном образе). Тем не менее, это, конечно, будет очень некрасиво, если вы должны были пойти опрыскивая дополнительные примерки, кроме блоков всего кода, чтобы сделать глобальные изменения, как исключения обрабатываются!

Ответил 30/03/2009 в 05:53
источник пользователем Carl Meyer

голоса

1

http://groups.google.com/group/django-nashville/browse_thread/thread/b4a258250cfa285a?pli=1

Ответил 13/11/2009 в 06:24
источник пользователем jaimechen

Jason Baker · Accepted Answer · 2009-03-27 20:51

Это немного экстремальный, но для целей отладки, вы можете включить DEBUG_PROPAGATE_EXCEPTIONSнастройки. Это позволит вам создать свою собственную обработку ошибок. Самый простой способ настроить сказал обработки ошибок будет переопределить sys.excepthook . Это прекратит свое приложение, но он будет работать. Там могут быть вещи , которые вы можете сделать , чтобы сделать это не убить ваше приложение, но это будет зависеть от того, какую платформу вы устанавливаете это для. Во всяком случае, никогда не использовать это в производстве!

Для производства, вы в значительной степени будете иметь обширные обработки ошибок на месте. Один из методов, я использовал что-то вроде этого:

>>> def log_error(func):
...     def _call_func(*args, **argd):
...         try:
...             func(*args, **argd)
...         except:
...             print "error" #substitute your own error handling
...     return _call_func
...
>>> @log_error
... def foo(a):
...     raise AttributeError
...
>>> foo(1)
error

Если вы используете log_error как декоратор на ваш взгляд, он будет автоматически обрабатывать любые ошибки произошло внутри него.

Процесс _функция исключения вызываются для некоторых исключений (например , утверждает (False) в views.py) , но процесс _исключение не вызывалось для других ошибок , как ImportErrors (например: импорт thisclassdoesnotexist в urs.py). Я новичок в Django / Python. Является ли это из - за некоторые различия между временем выполнения и во время компиляции ошибками?

В Python, все ошибки ошибки во время выполнения. Причина, почему это вызывает проблемы, потому что эти ошибки возникают сразу, когда модуль импортируется до вашего зрения не называл. Первый метод, который я отправил будет отлавливать ошибки, как это для отладки. Вы можете быть в состоянии понять что-то для производства, но я бы утверждать, что у вас есть более серьезные проблемы, если вы получаете ImportErrors в версии приложения (и вы не делаете любой динамический импорт).

Инструмент как pylint может помочь вам устранить эти виды проблем , хотя.