I think "letting to explode" is all about coloring the bike shed. It all depends on a API contract - if parameter is required (thus meaning missing it is a critical error) it should explode.
In case of incorrect request I prefer to raise 400 (Bad Request) with some explanation what went wrong. Since 500 is usually meant for "catch all" unexpected errors that happened in web server and server can't be more precise what happened. I've done that according to RFC 2616 (HTTP 1.1 Specification) where is said that 4xx codes are meant for "client side error" (Section 10.4), and 5xx which means "server error" (Section 10.5) But I think all of that is matter of taste... On Sun, Jul 15, 2012 at 12:23 AM, Melvyn Sopacua <m.r.sopa...@gmail.com>wrote: > [reformatted] > > On 11-7-2012 20:41, Jani Tiainen wrote: > > On Wed, Jul 11, 2012 at 4:47 PM, Andre Schemschat <dai...@web.de> wrote: > >> In my view i have, naturally, some code to process the request and > return > >> a response. This code needs a get-parameter to operate within boundaries > >> and this parameter is always provided within the application (Its an > >> ajax-callback). > > I only do 500-errors when something really critical happens (basically > > programming error) in application and request can't proceed. > > Which is why letting this explode on itself is a good thing. Your ajax > call should ensure the parameter is there. So when you get 500 errors > one of three things is happening: > - A browser does not handle the Ajax call correctly and you want the 500 > error context mailed to you to start debugging > - A crawler that tries to interpret javascript is not doing a very good > job and you want to update your robots.txt or block the crawler if it > doesn't seem to be respecting it. > - You refactored the javascript code or upgraded a js library and there > now is a codepath that doesn't provide the parameter. Again, you want to > see the information and probably catch it before it goes into production. > > Masking or reducing errors that should not normally happen is not a good > thing. This is exactly what exceptions are for. > -- > Melvyn Sopacua > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Jani Tiainen - Well planned is half done, and a half done has been sufficient before... -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
