Re: raising HttpResponseBadRequest throws Exception Type error?
On Jul 5, 7:33 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Having an exception > for every possible response code is really overkill here, since it means > you'll be raising status-code-related exceptions instead of more > semantic ones. Ah, makes sense. > > * Shouldn't Django be consistent in its own raising of errors and > > choose one way to do it (e.g. choose #1 above over #2)? Out of > > curiosity I grep'd the code to count how many chose the paren method > > vs the comma method: > > Meh. They're both perfectly valid Python and people should be able to > read either. It really makes no significant difference at all. I tend to > use the parenthesised version in my own code (partly because it's easier > to split across multiple lines), but the other form is just as readable. Agreed. Not worth it. Thanks for the reply Malcolm. Very informative as always. -Rob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: raising HttpResponseBadRequest throws Exception Type error?
On Sat, 2008-07-05 at 18:58 -0700, Rob Hudson wrote: [...] > * Shouldn't all HTTP error code raising function similarly? Shouldn't > I be able to raise a 400 error the same as a 404? Not really. Django has a 404 exception as a quick bail out for when something is missing and it and PermissionDenied are treated specially in the response handlers (although it's often not appropriate to let your code rely on that default handling). However, HTTP response codes are really a consequence of other errors -- they are a way to communicate that a certain type of error occured back to the client. Having an exception for every possible response code is really overkill here, since it means you'll be raising status-code-related exceptions instead of more semantic ones. Create your own "BadAPIVoodoo" exception, catch it in your view and return an HttpResponseBadRequest class. That enables you to write code that isn't tied to the HTTP processing pipeline and where the exceptions are more descriptive if they don't end up being routed straight to the user. You could compromise and create "RobsOwnHTTPException" that takes a status code and a message and then your view wrapper can convert it to the right request type. :-) Of course, all this is (my very own) personal opinion. But I have a lot of reusable code fragments (functions of half a dozen to a few dozen lines) that I'm using in multiple places and multiple projects and I think they're much stronger from raising well-named exceptions rather than going directly to HTTP response codes. Because I don't always raise the same response code for the same exception type, For example, if somebody tries to look up something about a member on one site, they get a 404 if the URL doesn't exist and they're a site admin or a "permission denied" if they wouldn't be able to view that member under any circumstances. The code determining the existence of the resource doesn't know that, though. > * Shouldn't Django be consistent in its own raising of errors and > choose one way to do it (e.g. choose #1 above over #2)? Out of > curiosity I grep'd the code to count how many chose the paren method > vs the comma method: Meh. They're both perfectly valid Python and people should be able to read either. It really makes no significant difference at all. I tend to use the parenthesised version in my own code (partly because it's easier to split across multiple lines), but the other form is just as readable. The drawback of making somewhat arbitrary changes like this is that it means the "last changed" date on that line changes when viewing it through "svn annotate" or similar and that information is often pretty useful for tracking down bugs: you can see that "this block of code was all changed at once" at a glance. Yes, some people get very determined that everything should be consistent, but this does fall into the trap of continually rewriting the code to match evolving styles and that's a productivity and maintainability sinkhole. As long as something isn't unnecessarily complex or unreadable, existing code will normally not be worth a rewrite. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
raising HttpResponseBadRequest throws Exception Type error?
In my code for an API it made sense to me to import and raise
`HttpResponseBadRequest ` when the API was given bad data to work
with. I'm importing and raising the error like this:
from django.http import Http404, HttpResponseBadRequest
raise HttpResponseBadRequest, "Invalid data"
But when I do that, I get a TypeError:
Exception Type: TypeError at /api/v1/clips/new/
Exception Value: exceptions must be classes, instances, or strings
(deprecated), not type
I thought this was similar to Http404 until I looked at the code in
django/http/__init__.py and see that the Http404 is subclassing
Exception while most of the other "errors" subclass HttpResponse. And
there is even a HttpResponseNotFound that has a status_code of 404 to
confuse matters even more.
I also grep'd the codebase to see what was the proper way to raise an
error and saw two ways:
1) raise Http404("Error message here.")
2) raise Http404, "Error message here."
I tried both for my `HttpResponseBadRequest` and still got a type
error. Following the logic that this is just a subclasses
HttpResponse I changed it to a return:
return HttpResponseBadRequest("Error message here.")
and that worked.
In the end I was a bit confused by all of this and came away wondering:
* Shouldn't all HTTP error code raising function similarly? Shouldn't
I be able to raise a 400 error the same as a 404?
* Shouldn't Django be consistent in its own raising of errors and
choose one way to do it (e.g. choose #1 above over #2)? Out of
curiosity I grep'd the code to count how many chose the paren method
vs the comma method:
~/sandbox/django/django_trunk/django > egrep -R 'raise \w+\(.*' * |
grep -v .svn | wc -l # paren method
371
~/sandbox/django/django_trunk/django > egrep -R 'raise \w+,.*' * |
grep -v .svn | wc -l # comma method
184
-Rob
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
