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