Hi, not answering exactly what you asked, by my 2 cents anyway:
Why do you want to do this? Why does the user care whether the error was in the database or a bug in your program or a filesystem error or a network error or Redis being down or whatever? Neither is this information useful nor is it interesting to the user. Plus it introduces unnecessary complexity in your code. Possibly a better way of doing that is to use handler500 <https://docs.djangoproject.com/en/1.11/ref/urls/#handler500>. However, attempting to do smart things when an error has occurred is quite risky and more often than not it doesn't work. So I am against changing the default handler500 with no compelling reason. Usually just defining a nice 500.html <https://docs.djangoproject.com/en/1.11/ref/views/#the-500-server-error-view> file is all you need. Regards, Antonis Antonis Christofides http://djangodeployment.com On 2017-06-07 10:15, Damian Myerscough wrote: > Hello, > > I have setup a Django project that is being served via Nginx + gunicorn, > however, I would like to handle graceful database failures. > For example, if the ORM cannot query the database I would like to return a > custom error message. > > > ==> gunicorn.log <== > [2017-06-07 06:06:01 +0000] [13] [DEBUG] GET /incidents/ > [2017-06-07 06:06:11 +0000] [8] [CRITICAL] WORKER TIMEOUT (pid:13) > [2017-06-07 06:06:11 +0000] [13] [INFO] Worker exiting (pid: 13) > [2017-06-07 06:06:11 +0000] [20] [INFO] Booting worker with pid: 20 > > ==> nginx-error.log <== > 2017/06/07 06:06:11 [error] 9#9: *1 upstream prematurely closed connection > while reading response header from upstream, client: 172.17.0.1, s > erver: XXXX, request: "GET /incidents/ HTTP/1.1", upstream: > "http://unix:/webapp/run/gunicorn.sock:/incidents/";, host: "192 > .168.99.102:30061" > > > I am using the following code snippet to test this, however, the json response > is not sent back > > try: > incidents = > Incidents.objects.filter(user_and_team=request.user.client).exclude(status="Resolved") > except OperationalError: > return JsonResponse( > {"error": trans("We encountered a problem")}, > status=status.HTTP_503_SERVICE_UNAVAILABLE, > ) > > Any ideas? > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com > <mailto:django-users+unsubscr...@googlegroups.com>. > To post to this group, send email to django-users@googlegroups.com > <mailto:django-users@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/719ff783-b448-4644-970e-34282185465a%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/719ff783-b448-4644-970e-34282185465a%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5bf42882-1fbf-46d1-da97-518300b8893d%40djangodeployment.com. For more options, visit https://groups.google.com/d/optout.
