Catch or raise exception designissue

2012-07-31 Thread 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 > wrote: > I think "letting to explode" is all about coloring the

Re: Catch or raise exception designissue

2012-07-24 Thread 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

Re: Catch or raise exception designissue

2012-07-15 Thread 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.

Re: Catch or raise exception designissue

2012-07-15 Thread 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 :) On

Re: Catch or raise exception designissue

2012-07-14 Thread Melvyn Sopacua
[reformatted] On 11-7-2012 20:41, Jani Tiainen wrote: > On Wed, Jul 11, 2012 at 4:47 PM, Andre Schemschat 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

Re: Catch or raise exception designissue

2012-07-11 Thread 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,

Catch or raise exception designissue

2012-07-11 Thread 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