Συνδεθείτε όλα τα σφάλματα στην κονσόλα ή το αρχείο στο Django ιστοσελίδα

Question

Συνδεθείτε όλα τα σφάλματα στην κονσόλα ή το αρχείο στο Django ιστοσελίδα

ψήφοι

13

Πώς μπορώ να πάρω Django 1.0 για να γράψει όλα τα λάθη στην κονσόλα ή ένα αρχείο καταγραφής όταν τρέχει runserver σε κατάσταση εντοπισμού σφαλμάτων;

Έχω δοκιμάσει χρησιμοποιώντας μια κατηγορία middleware με τη λειτουργία process_exception όπως περιγράφεται στην αποδεκτή απάντηση στο ερώτημα αυτό:

Πώς μπορείτε να συνδεθείτε σφάλματα διακομιστή στον ιστότοπό Django

Η λειτουργία process_exception καλείται για ορισμένες εξαιρέσεις (π.χ. διεκδικούν (Ψευδές) σε views.py), αλλά process_exception δεν παίρνει έκκληση για άλλα λάθη όπως ImportErrors (π.χ. thisclassdoesnotexist εισαγωγής urs.py). Είμαι νέος στο Django / Python. Είναι αυτό γιατί κάποια διάκριση μεταξύ χρόνου εκτέλεσης και κατάρτιση σφάλματα χρόνου; Στη συνέχεια, όμως θα περίμενα runserver να διαμαρτύρονται αν ήταν ένα σφάλμα μεταγλώττισης και δεν το κάνει.

Έχω προσέξει φανταστική παρουσίαση του Simon Willison για Django debugging ( http://simonwillison.net/2008/May/22/debugging/ ), αλλά δεν είδα μια επιλογή που θα μπορούσε να λειτουργήσει καλά για μένα.

Σε περίπτωση που αυτό είναι σχετικό, γράφω ένα app του Facebook και του Facebook μάσκες HTTP 500 σφάλματα με το δικό τους μήνυμα αντί να δείχνει φοβερά ενημερωτικό 500 σελίδα του Django του. Γι 'αυτό χρειάζονται έναν τρόπο για όλα τα είδη των λαθών που θα γραφτεί στην κονσόλα ή αρχείο.

Επεξεργασία: Υποθέτω προσδοκία μου είναι ότι αν Django μπορεί να επιστρέψει μια σελίδα 500 λάθους με πολλές λεπτομέρειες, όταν έχω μια κακή εισαγωγής (ImportError) σε urls.py, θα πρέπει να είναι σε θέση να γράψει την ίδια λεπτομέρεια στην κονσόλα ή ένα αρχείο χωρίς να χρειάζεται να προσθέσετε οποιοδήποτε επιπλέον χειρισμό εξαίρεση στον κώδικα. Δεν έχω δει ποτέ χειρισμό εξαίρεση γύρω από τις δηλώσεις εισαγωγής.

Ευχαριστώ, Jeff

python django facebook

Δημοσιεύθηκε 27/03/2009 στις 18:30
πηγή χρήστη jlpp

Σε άλλες γλώσσες...

5 απαντήσεις

ψήφοι

2

Πρώτον, υπάρχουν πολύ λίγες μεταγλώττισης χρόνου λάθη που θα δείτε μέσα από ένα ημερολόγιο εξαίρεση. Εάν ο κωδικός Python σας δεν έχει έγκυρη σύνταξη, πεθαίνει πολύ πριν από τα αρχεία καταγραφής ανοίξει για το γράψιμο.

Σε λειτουργία runserver Django, μια δήλωση «εκτύπωση», γράφει στο stdout, που μπορείτε να δείτε. Αυτό δεν είναι μια καλή μακροπρόθεσμη λύση, όμως, έτσι δεν μετράνε σε αυτό.

Όταν Django λειτουργεί υπό Apache, ωστόσο, εξαρτάται από το plug-in που χρησιμοποιείτε. mod_python δεν είναι εύκολο να αντιμετωπίσουμε. mod_wsgi μπορεί να εξαναγκάζονται να στείλει stdout και stderr σε ένα αρχείο καταγραφής.

Ο καλύτερος τρόπος, όμως, είναι η καταγραφή της μονάδας. Βάλτε ένα προετοιμασίας σε ανώτερου επιπέδου urls.pyγια να ρυθμίσετε την υλοτομία. (Ή, ίσως, σας settings.py)

Να είστε βέβαιος ότι κάθε μονάδα έχει ένα καταγραφικό διαθέσιμο για τη σύνταξη μηνυμάτων καταγραφής.

Να είστε βέβαιος ότι κάθε διαδικτυακές υπηρεσίες κλήση που κάνετε έχει μια δοκιμή / εκτός από μπλοκ γύρω από αυτό, και να σας γράψω τις εξαιρέσεις ημερολόγιο σας.

Απαντήθηκε 27/03/2009 στις 19:51
πηγή χρήστη S.Lott

ψήφοι

-1

Αν είστε σε ένα σύστημα * nix θα μπορούσατε

γράψετε σε ένα αρχείο καταγραφής (π.χ.. MyLog.txt) σε python στη συνέχεια, εκτελέστε «tail -f MyLog.txt» στην κονσόλα

Αυτό είναι ένας εύκολος τρόπος για να δείτε οποιοδήποτε είδος της καταγραφής σε σχεδόν πραγματικό χρόνο

Απαντήθηκε 28/03/2009 στις 23:03
πηγή χρήστη

ψήφοι

6

Η λειτουργία process_exception καλείται για ορισμένες εξαιρέσεις (π.χ. διεκδικούν (Ψευδές) σε views.py), αλλά process_exception δεν παίρνει έκκληση για άλλα λάθη όπως ImportErrors (π.χ. thisclassdoesnotexist εισαγωγής urs.py). Είμαι νέος στο Django / Python. Είναι αυτό γιατί κάποια διάκριση μεταξύ χρόνου εκτέλεσης και κατάρτιση σφάλματα χρόνου;

Όχι, είναι μόνο και μόνο επειδή process_exception middleware καλείται μόνο εάν μια εξαίρεση που θίγονται στην προβολή .

Νομίζω ότι DEBUG_PROPAGATE_EXCEPTIONS (όπως αναφέρεται για πρώτη φορά από τον Jason Baker) είναι ό, τι χρειάζεστε εδώ, αλλά δεν νομίζω ότι δεν χρειάζεται να κάνετε τίποτα επιπλέον (δηλαδή sys.excepthook, κλπ), αν απλά θέλετε το traceback που αποτελούν αντικείμενο ντάμπινγκ στην κονσόλα.

Αν θέλετε να κάνετε κάτι πιο πολύπλοκο με το σφάλμα (δηλαδή χωματερή να καταθέσει ή DB), η απλούστερη προσέγγιση θα ήταν η σήμα 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 ως διακοσμητής για την άποψή σας, θα χειριστεί αυτόματα ό, τι τα λάθη που συνέβη μέσα σε αυτό.

Η διαδικασία _λειτουργίας εξαίρεση καλείται για ορισμένες εξαιρέσεις (π.χ. διεκδικούν (Ψευδές) σε views.py), αλλά η διαδικασία _εξαίρεσης δεν παίρνει έκκληση για άλλα λάθη όπως ImportErrors (π.χ. thisclassdoesnotexist εισαγωγής urs.py). Είμαι νέος στο Django / Python. Είναι αυτό γιατί κάποια διάκριση μεταξύ χρόνου εκτέλεσης και κατάρτιση σφάλματα χρόνου;

Στην Python, όλα τα σφάλματα είναι τα σφάλματα χρόνου εκτέλεσης. Ο λόγος για τον οποίο αυτό προκαλεί προβλήματα είναι γιατί αυτά τα λάθη συμβαίνουν αμέσως όταν η μονάδα έχει εισαχθεί πριν από την άποψή σας ονομάζεται ποτέ. Η πρώτη μέθοδος που δημοσιεύτηκε θα πιάσει λάθη, όπως αυτά για τον εντοπισμό σφαλμάτων. Ίσως να είναι σε θέση να καταλάβω κάτι για την παραγωγή, αλλά θα ήθελα να ισχυρίζονται ότι έχετε χειρότερα προβλήματα αν παίρνετε ImportErrors σε μια εφαρμογή την παραγωγή (και δεν έχετε κάνει καμία δυναμική εισαγωγή).

Ένα εργαλείο όπως pylint μπορεί να σας βοηθήσει να εξαλειφθούν τέτοιου είδους προβλήματα όμως.