[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
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
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.
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
[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
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,
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
7 matches
Mail list logo