Tuesday, July 31, 2012

Catch or raise exception designissue

[sorry for the late response; this got lost in drafts, but it's enough of a sore point for me to want to post it]

On Sun, Jul 15, 2012 at 12:30 PM, Jani Tiainen <redetin@gmail.com> wrote:
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...


I wouldn't call it a matter of taste; this is the spec for communicating over HTTP.

Certainly, if you have full and complete control over the server, and over every client, then by all means use 500 errors to mean whatever you want. You could also signal an error with a 200 OK message, or just make up your own status codes.

Status codes have meaning though, which is important as soon as you want to open up your interface to any other clients. A 400-series code means that the client request had a problem, and the specific code tells the client whether there is anything that can be done about it.

A 500 error, on the other hand, means that there is an error (read: bug) in the web server code. Something happened (almost certainly in response to a client request) that the server was not properly coded to handle, and the result was an unexpected exception.

The distinction is important: it communicates who has the responsibility (or at least the capability) to fix the error.

As developers, we should be reporting 400-series errors every time we can detect an issue with a request, as a courtesy to clients. We should never deliberately be creating 500 errors. The only responsible thing to do when a 500 is seen in the logs is to track down the source of it and fix the bug.

--
Regards,
Ian Clelland
<clelland@gmail.com>


--
Regards,
Ian Clelland
<clelland@gmail.com>

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

No comments:

Post a Comment