Log tutti gli errori di consolare o file sul sito Django

Question

Log tutti gli errori di consolare o file sul sito Django

voti

13

Come posso ottenere Django 1.0 a scrivere tutti gli errori alla console o un file di log durante l'esecuzione runserver in modalità debug?

Ho provato con una classe middleware con funzione di process_exception come descritto nella risposta accettata a questa domanda:

Come si accede errori del server su siti Django

La funzione process_exception viene chiamata per alcune eccezioni (ad esempio: assert (Falso) in views.py), ma process_exception non è sempre chiamato per altri errori come ImportErrors (ad esempio: import thisclassdoesnotexist in urs.py). Sono nuovo a Django / Python. È questo a causa di una certa distinzione tra fase di esecuzione e in fase di compilazione errori? Ma poi mi aspetterei runserver a lamentarsi se si trattava di un errore di compilazione e non è così.

Ho guardato fantastica presentazione di Simon Willison su Django debugging ( http://simonwillison.net/2008/May/22/debugging/ ), ma non ho visto un'opzione che avrebbe funzionato bene per me.

Nel caso in cui è rilevante, sto scrivendo un applicazione Facebook e Facebook maschere HTTP 500 errori con il proprio messaggio, piuttosto che mostrare incredibilmente informativo pagina di Django 500. Quindi ho bisogno di un modo per tutti i tipi di errori da scrivere alla console o al file.

Edit: Credo che la mia aspettativa è che se Django può restituire una pagina di errore 500 con un sacco di dettagli quando ho un cattivo di importazione (ImportError) in urls.py, dovrebbe essere in grado di scrivere lo stesso dettaglio per la console o un file senza dover aggiungere alcun ulteriore gestione delle eccezioni al codice. Non ho mai visto la gestione delle eccezioni in giro istruzioni import.

Grazie, Jeff

python django facebook

È pubblicato 27/03/2009 alle 18:30
fonte dall'utente jlpp

In altre lingue...

5 risposte

voti

2

In primo luogo, ci sono pochissimi errori di compilazione che vedrete attraverso un registro di un'eccezione. Se il codice Python non ha sintassi valida, si muore molto prima che i registri sono aperti per la scrittura.

In modalità runserver Django, una dichiarazione "stampa", scrive su stdout, che si può vedere. Questa non è una buona soluzione a lungo termine, tuttavia, in modo da non contare su di esso.

Quando Django è in esecuzione con Apache, tuttavia, dipende da quale plug-in che si sta utilizzando. mod_python non è facile da affrontare. mod_wsgi può essere costretti a inviare stdout e stderr in un file di log.

La cosa migliore, tuttavia, è la registrazione del modulo. Mettere un'inizializzazione nel vostro livello superiore urls.pyper configurare la registrazione. (O, forse, la tua settings.py)

Assicurarsi che ogni modulo ha un logger a disposizione per la scrittura di messaggi di log.

Assicurarsi che ogni servizi web chiamata effettuata ha un blocco try / except intorno ad esso, e si scrivono le eccezioni per il registro.

Risposto il 27/03/2009 a 19:51
fonte dall'utente S.Lott

voti

-1

Se siete su un sistema * nix si potrebbe

scrivere in un registro (ad es. mylog.txt) in python quindi eseguire "coda mylog.txt -f" nella console

questo è un modo pratico per visualizzare qualsiasi tipo di log in tempo reale

Risposto il 28/03/2009 a 23:03
fonte dall'utente

voti

6

La funzione process_exception viene chiamata per alcune eccezioni (ad esempio: assert (Falso) in views.py), ma process_exception non è sempre chiamato per altri errori come ImportErrors (ad esempio: import thisclassdoesnotexist in urs.py). Sono nuovo a Django / Python. È questo a causa di una certa distinzione tra fase di esecuzione e in fase di compilazione errori?

No, è solo perché process_exception middleware viene chiamato solo se viene generata un'eccezione nella vista .

Penso DEBUG_PROPAGATE_EXCEPTIONS (come menzionato prima da Jason Baker) è quello che serve qui, ma non credo che non c'è bisogno di fare nulla in più (cioè sys.excepthook, ecc) se si desidera solo il traceback scaricato per consolare.

Se si vuole fare qualcosa di più complesso con l'errore (cioè dump file o DB), l'approccio più semplice sarebbe il segnale di got_request_exception , che Django invia alcuna eccezione richiesta correlata, se è stato sollevato nella vista oppure no.

I Get_Response e handle_uncaught_exception metodi di django.core.handlers.BaseHandler sono istruttivi (e breve) lettura in questo settore.

senza dover aggiungere qualsiasi ulteriore gestione delle eccezioni al codice. Non ho mai visto la gestione delle eccezioni in giro istruzioni import.

Guardatevi intorno un po 'di più, lo vedrai fatto (spesso nei casi in cui si desidera gestire l'assenza di una dipendenza in qualche modo particolare). Detto questo, sarebbe ovviamente essere molto brutto se si doveva andare aspersione ulteriore try-tranne che blocca tutto il codice per fare un cambiamento globale di come le eccezioni vengono gestite!

Risposto il 30/03/2009 a 05:53
fonte dall'utente Carl Meyer

voti

1

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

Risposto il 13/11/2009 a 06:24
fonte dall'utente jaimechen

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

E 'un po' estrema, ma a scopo di debug, è possibile attivare l' DEBUG_PROPAGATE_EXCEPTIONSimpostazione. Questo vi permetterà di impostare la propria gestione degli errori. Il modo più semplice per impostare detto la gestione degli errori sarebbe quello di ignorare sys.excepthook . In questo modo interrompere l'applicazione, ma funzionerà. Ci possono essere cose che potete fare per rendere questo non uccide la vostra applicazione, ma questo dipenderà da quale piattaforma si sta distribuendo questo per. In ogni caso, non utilizzare questo in produzione!

Per la produzione, si sta praticamente andando ad avere per avere una vasta gestione degli errori in posto. Una tecnica che ho usato è qualcosa di simile:

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

Se si utilizza LOG_ERROR come decoratore sulla vostra vista, gestirà automaticamente gli errori che è accaduto all'interno di esso.

Il processo di _funzione di eccezione viene chiamata per alcune eccezioni (ad esempio: assert (Falso) in views.py), ma processo di _eccezione non è sempre chiamato per altri errori come ImportErrors (ad esempio: import thisclassdoesnotexist in urs.py). Sono nuovo a Django / Python. È questo a causa di una certa distinzione tra fase di esecuzione e in fase di compilazione errori?

In Python, tutti gli errori sono errori di runtime. Il motivo per cui questo sta causando problemi è perché questi errori si verificano immediatamente quando il modulo viene importato prima del tuo punto di vista è sempre chiamato. Il primo metodo che ho postato prenderà errori come questi per il debug. Potreste essere in grado di capire qualcosa per la produzione, ma direi che si hanno problemi peggiori se stai ricevendo ImportErrors in un'applicazione di produzione (e non stai facendo qualsiasi importazione dinamica).

Uno strumento come pylint può aiutare a eliminare questi tipi di problemi però.