Catch or raise exception designissue

[Andre Schemschat]

Hi everybody,

i'm currently working on my first django-application and stumbled upon a design issue, which i cant quite decide how to handle and i thought i may ask here, if there are any guidelines as to how to handle this :)

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).

The question now is, what to do if the parameter is not provided somehow. Should i catch the resulting KeyError (Or any unexpected exception in any view for that matter) and just redirect to a safe page, log the error away and display a warning to the user or should i just let the error pass (in debug show the error info page, in production the 500-page), since it shouldnt have happend within the application?

I'm currently tending towards the second option, because in production there is the 500-page, so the user doesnt get to see ugly errors and with an error-handling middleware i can log the exceptions and in debug its easier to take care of the bug, but i like to hear some opinions from the more experienced django-devs in here, cause i'm sure im missing some vital point :D

Thanks&Grettings,

Andre

[Jani Tiainen]

It all depends what is "natural" for end user point of view.

If parameter is something like start or end value I think that the most convenient thing is to provide some reasonable default if variable is missing or is incorrect type. Then you may use logging facility to log to some logger (debug, warn, errror) that value provided was incorrect and was replaced by default value.

I only do 500-errors when something really critical happens (basically programming error) in application and request can't proceed.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/bQyS-29Lb4QJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@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...

[Melvyn Sopacua]

[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

[Andre Schemschat]

Hey,

thanks for your replies. so the general idea is to dont catch the 500's, if there really is an situation which shouldnt happen. Thats was my first thought too, so i think i will stick with that and just code defensivly with exception-raising, when critical situations appear :)

[Jani Tiainen]

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...

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Melvyn Sopacua]

On 15-7-2012 21:30, Jani Tiainen wrote:

> 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)

Yeah, this is one of the harder ones. Is it still a client error if she
clicks a server generated link? ;)

--
Melvyn Sopacua

[Ian Clelland]

[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 <red...@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
<clel...@gmail.com>


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