Re: Catch or raise exception designissue

[reformatted]

On 11-7-2012 20:41, Jani Tiainen wrote:
> On Wed, Jul 11, 2012 at 4:47 PM, Andre Schemschat <Daishy@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.