Hmm, looking at the code that existed before the filterwarnings promotion to error, the older code was catching Database.Warning exceptions and re-raising them with the warning information included. This was before my time but it seems the older code was simply making the exceptions raised for DB warnings more informative in DEBUG mode, by fetching and including the warning text in the exception?
I agree it seems odd to have warnings turned into exceptions for DEBUG=True only. While it is longstanding behavior it doesn't make much sense nowadays when Django has better logging support (so developers can hopefully "see" the warnings if just logged as such) and MySQL has moved more towards having strict mode be the default. I think it would make sense to get rid of this behavior and just log MySQL warnings as warnings. Karen -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACS9rafJxXS3a6rf83gTb5VJ9Po7G7_fjgFBPqV35H%3D3b5rs9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
