Zaznamenávat všechny chyby na konzoli nebo soubor na webu Django

Question

Zaznamenávat všechny chyby na konzoli nebo soubor na webu Django

hlasů

13

Jak mohu získat Django 1.0 zapisovat všechny chyby na konzoli nebo soubor protokolu při spuštění runserver v režimu ladění?

Snažil jsem se pomocí třídy middleware s funkcí process_exception, jak je popsáno v přijatém odpovědi na tuto otázku:

Jak se přihlásit chyby serveru na Django míst

Funkce process_exception je vyžadována některými výjimkami (např: assert (False) v views.py), ale process_exception není stále volal po jiných chyb, jako je ImportErrors (např: import thisclassdoesnotexist v urs.py). Jsem nový Django / Python. Je to proto, že z nějakého rozdílu mezi běhu a kompilace-time chyby? Ale pak bych očekával runserver stěžovat, pokud se jednalo o chybu v době kompilace a to tak není.

Sledoval jsem Simon Willison je skvělou prezentaci na Django ladění ( http://simonwillison.net/2008/May/22/debugging/ ), ale neviděl jsem možnost, že by dobře fungovat pro mě.

V případě, že je to důležité, píšu aplikace Facebook a Facebook masky HTTP 500 chyb, spíše než jejich vlastní zprávy ukazující úžasně informativní 500 stránku Djangovo. Tak jsem třeba způsob, jak pro všechny druhy chyb, které mají být zapsány do konzoly nebo souboru.

Edit: Myslím, že moje očekávání je, že pokud Django může vrátit stránku 500 Chyba se spoustou detailů, když mám špatnou import (ImportError) v urls.py, měl by být schopen psát stejný detail na konzoli nebo soubor, aniž museli přidávat žádné další zpracování výjimek kódu. Nikdy jsem neviděl zpracování výjimek kolem dovozních prohlášení.

Díky, Jeff

python django facebook

Položena 27/03/2009 v 18:30
zdroj uživatelem jlpp

V jiných jazycích...

5 odpovědí

hlasů

2

Za prvé, existuje jen velmi málo času kompilace chyby, které budete vidět přes protokolu výjimek. Pokud váš Python kód nemá platnou syntaxi, zemře dlouho předtím, než protokoly jsou otevřeny pro zápis.

V režimu Django runserver, prohlášení „print“ píše na standardní výstup, který si můžete prohlédnout. To není dobré dlouhodobé řešení, nicméně, takže se nemusíte spoléhat na to.

Když Django běží pod Apache, ale záleží na tom, které plug-in, který používáte. mod_python není snadné se vypořádat s. mod_wsgi mohou být nuceny posílání stdout a stderr do souboru protokolu.

Nejlepším řešením, nicméně, je protokolování modulu. Dal inicializaci do své nejvyšší úrovně urls.pykonfigurace protokolování. (Nebo snad vaše settings.py)

Ujistěte se, že každý modul má záznamník k dispozici pro psaní zpráv protokolu.

Ujistěte se, že každé webové služby volání uděláte má bloku try / except kolem něj, a píšete výjimky do svého deníku.

Odpovězeno 27/03/2009 v 19:51
zdroj uživatelem S.Lott

hlasů

-1

Pokud jste na nix systém * bys mohl

zapsat do protokolu (např. mylog.txt) v pythonu spusťte „tail -f mylog.txt“ v konzoli

To je praktický způsob, jak zobrazit jakýkoliv druh záznamu téměř v reálném čase

Odpovězeno 28/03/2009 v 23:03
zdroj uživatelem

hlasů

6

Funkce process_exception je vyžadována některými výjimkami (např: assert (False) v views.py), ale process_exception není stále volal po jiných chyb, jako je ImportErrors (např: import thisclassdoesnotexist v urs.py). Jsem nový Django / Python. Je to proto, že z nějakého rozdílu mezi běhu a kompilace-time chyby?

Ne, je to jen proto, že process_exception middleware je volána pouze v případě, že výjimka je aktivována v zobrazení .

Myslím, že DEBUG_PROPAGATE_EXCEPTIONS (jak je uvedeno dříve Jason Baker), je to, co budete potřebovat tady, ale nemyslím si, že nemusíte nic dělat další (tj sys.excepthook, etc) jen chcete-li vám traceback dumpingové utěšit.

Chcete-li dělat nic víc komplex s chybou (tj skládka je do souboru nebo DB), nejjednodušší postup by byl got_request_exception signál , který Django pošle pro jakoukoli výjimku žádosti související, ať už to byl zvýšen v zobrazení či nikoliv.

Tyto GET RESPONSE a handle_uncaught_exception metody django.core.handlers.BaseHandler jsou poučné (a stručný) čtení v této oblasti.

aniž by bylo nutné přidávat žádné dodatečné zpracování výjimek kódu. Nikdy jsem neviděl zpracování výjimek kolem dovozních prohlášení.

Rozhlédněte se kolem sebe trochu víc, uvidíte to udělat (často v případech, kdy chcete zvládnout absenci závislostí nějakým zvláštním způsobem). To znamená, že by to ovšem bylo docela ošklivý, pokud jste měli jít kropení další try-kromě bloků po celém kódu provést globální změnu, jak jsou výjimky zacházet!

Odpovězeno 30/03/2009 v 05:53
zdroj uživatelem Carl Meyer

hlasů

1

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

Odpovězeno 13/11/2009 v 06:24
zdroj uživatelem jaimechen

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

Je to trochu extrémní, ale pro účely ladění, můžete zapnout DEBUG_PROPAGATE_EXCEPTIONSnastavení. To vám umožní nastavit svůj vlastní zpracování chyb. Nejjednodušší způsob, jak nastavit řekl zpracování chyb by bylo přepsat sys.excepthook . To ukončí svou přihlášku, ale to bude fungovat. Tam může být věci, které můžete udělat, aby to není zabije vaši aplikaci, ale to bude záležet na tom, co platforma jste nasazení to pro. V každém případě, nikdy použít ve výrobě!

Pro výrobu, budete do značné míry bude mít rozsáhlé zpracování chyb na místě. Jedna technika Použil jsem je něco jako toto:

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

Používáte-li log_error jako malíř na svém názoru, bude to automaticky zpracovávat bez ohledu na chyby se stalo v něm.

Proces _funkce Výjimkou je vyžadována některými výjimkami (např: assert (False) v views.py), ale proces _Výjimkou není stále volal po jiných chyb, jako je ImportErrors (např: import thisclassdoesnotexist v urs.py). Jsem nový Django / Python. Je to proto, že z nějakého rozdílu mezi běhu a kompilace-time chyby?

V Pythonu, všechny chyby jsou chyby run-time. Důvodem, proč je to způsobuje problémy je, že tyto chyby dojít okamžitě, když je modul dovezeny před váš názor je někdy nazýván. První metoda jsem vyslán zachytí chyby, jako ty pro ladění. Ty by mohly být schopni něco vymyslet pro výrobu, ale já bych tvrdit, že máte horší problémy, pokud jste stále ImportErrors ve výrobním aplikace (a vy neděláte žádnou dynamickou import).

Nástroj jako pylint vám pomůže tento druh problémů odstranit ačkoli.