Logg alle feil å trøste eller fil på Django stedet

Question

Logg alle feil å trøste eller fil på Django stedet

stemmer

13

Hvordan kan jeg få Django 1.0 til å skrive alle feil til konsollen eller en loggfil når du kjører runserver i feilsøkingsmodus?

Jeg har prøvd å bruke en mellomvare klasse med process_exception funksjon som er beskrevet i den aksepterte svaret på dette spørsmålet:

Hvordan logger du server feil på Django nettsider

Den process_exception funksjonen kalles for noen unntak (f.eks: hevde (usann) i views.py), men process_exception er ikke å bli kalt for andre feil som ImportErrors (f.eks: import thisclassdoesnotexist i urs.py). Jeg er ny på Django / Python. Er dette på grunn av noen forskjell mellom kjøretid og kompilere-time feil? Men da ville jeg forvente runserver til å klage hvis det var en samle-tid feil, og det gjør det ikke.

Jeg har sett Simon Willison fantastiske presentasjon på Django debugging ( http://simonwillison.net/2008/May/22/debugging/ ), men jeg fikk ikke se et alternativ som ville fungere bra for meg.

I tilfelle det er relevant, skriver jeg en Facebook-app og Facebook masker HTTP 500 feil med sitt eget budskap heller enn å vise Djangos awesomely informativ 500 side. Så jeg trenger en måte for alle typer feil å bli skrevet til konsollen eller filen.

Edit: Jeg tror min forventning er at hvis Django kan returnere en 500-feil side med masse detaljer når jeg har en dårlig import (ImportError) i urls.py, bør det være i stand til å skrive det samme detalj til konsollen eller en fil uten å legge noen ekstra avvikshåndtering til koden. Jeg har aldri sett avvikshåndtering rundt import uttalelser.

Takk, Jeff

python django facebook

Publisert på 27/03/2009 klokken 17:30
kilden bruker jlpp

På andre språk...

5 svar

stemmer

2

Først, det er svært få kompilere-time feil som du ser gjennom et unntak logg. Hvis Python-kode ikke har gyldig syntaks, dør det lenge før loggene er åpnet for skriving.

I Django runserver modus, skriver en "print" uttalelse til stdout, som du kan se. Dette er ikke en god langsiktig løsning, men så ikke stole på det.

Når Django kjører under Apache, men det avhenger av hvilken plug-in du bruker. mod_python er ikke lett å håndtere. mod_wsgi kan tvinges til å sende stdout og stderr til en loggfil.

Det beste alternativet, men er logging modulen. Sett en initialisering inn på øverste nivå urls.pyfor å konfigurere logging. (Eller kanskje din settings.py)

Vær sikker på at hver modul har en logger tilgjengelig for å skrive loggmeldinger.

Pass på at alle webtjenester samtale du gjør har en prøve / unntatt blokk rundt det, og du skriver unntak loggen.

Svarte 27/03/2009 kl. 18:51
kilden bruker S.Lott

stemmer

-1

Hvis du er på en * nix system du kan

skrive til en logg (f.eks. mylog.txt) i python deretter kjøre "tail-f mylog.txt" i konsollen

Dette er en praktisk måte å vise noen form for innlogging i nær sanntid

Svarte 28/03/2009 kl. 22:03
kilden bruker

stemmer

6

Den process_exception funksjonen kalles for noen unntak (f.eks: hevde (usann) i views.py), men process_exception er ikke å bli kalt for andre feil som ImportErrors (f.eks: import thisclassdoesnotexist i urs.py). Jeg er ny på Django / Python. Er dette på grunn av noen forskjell mellom kjøretid og kompilere-time feil?

Nei, det er bare fordi process_exception mellomvare er bare kalles hvis et unntak er hevet i visningen .

Jeg tror DEBUG_PROPAGATE_EXCEPTIONS (som nevnt først av Jason Baker) er det du trenger her, men jeg tror ikke du trenger ikke å gjøre noe ekstra (dvs. sys.excepthook, etc) hvis du bare vil at tilbakesporings dumpet til konsollen.

Hvis du ønsker å gjøre noe mer kompleks med feilen (dvs. dumpe det til fil eller DB), ville den enkleste tilnærmingen være got_request_exception signal , som Django sender for enhver forespørsel relaterte unntak, om det ble reist i visningen eller ikke.

De get_response og handle_uncaught_exception metoder for django.core.handlers.BaseHandler er lære (og kort) avlesning i dette området.

uten å legge noen ekstra avvikshåndtering til koden. Jeg har aldri sett avvikshåndtering rundt import uttalelser.

Se deg rundt litt mer, vil du se det gjort (ofte i tilfeller der du ønsker å håndtere fravær av en avhengighet i noen bestemt måte). Når det er sagt, ville det selvsagt være ganske stygg hvis du måtte gå sprinkling ekstra prøve-unntak blokkerer hele koden for å lage en global endring i hvordan unntakene håndteres!

Svarte 30/03/2009 kl. 04:53
kilden bruker Carl Meyer

stemmer

1

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

Svarte 13/11/2009 kl. 05:24
kilden bruker jaimechen

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

Det er litt ekstreme, men feilretting, kan du slå på DEBUG_PROPAGATE_EXCEPTIONSinnstillingen. Dette vil tillate deg å sette opp din egen feilhåndtering. Den enkleste måten å sette opp sa feilbehandling ville være å overstyre sys.excepthook . Dette vil avslutte programmet, men det vil fungere. Det kan være ting du kan gjøre for å gjøre dette ikke drepe app, men dette vil avhenge av hvilken plattform du distribuerer dette for. I alle fall aldri bruke dette i produksjon!

For produksjon, er du ganske mye kommer til å ha omfattende feilbehandling på plass. En teknikk jeg har brukt er noe sånt som dette:

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

Hvis du bruker log_error som dekoratør på ditt syn, vil den automatisk håndtere alt feil som skjedde i den.

Prosessen _unntak funksjonen kalles for noen unntak (f.eks: hevde (usann) i views.py), men prosessen _unntaket ikke får kalt for andre feil som ImportErrors (f.eks: import thisclassdoesnotexist i urs.py). Jeg er ny på Django / Python. Er dette på grunn av noen forskjell mellom kjøretid og kompilere-time feil?

I Python, alle feil er run-time feil. Grunnen til at dette skaper problemer er fordi disse feilene oppstår umiddelbart når modulen er importert før visningen er stadig kalt. Den første metoden jeg postet vil fange feil som disse for debugging. Du kan være i stand til å finne noe ut for produksjonen, men jeg vil hevde at du har verre problemer hvis du får ImportErrors i en produksjons app (og du ikke gjør noen dynamisk import).

Et verktøy som pylint kan hjelpe deg å eliminere slike problemer selv.