On Thu, May 26, 2011 at 6:15 AM, Daniel Holth <dho...@gmail.com> wrote: > 'return' makes sense because views return a response. Whether the response > has an error code of 200, 301 or 5xx is a separate concern. Of course > exceptions make sense too.
This only became an issue because HTTPException happens to be a WSGi application so it looks like a view return value. It would have been better if it were just an Exception subclass so there would be no question they should be raised and caught. In fact, I'm not even sure the body and headers of the HTTPException should be honored; it's really the job of the framework to decide how to display HTTP errors (possibly using a plugin such as an error-view to customize it). in Pylons, if the StatusCodeRedirect middleware is active, it makes a subrequest. If it's not active, something in Pylons or Paste generates a plain error message including the title, description, and (in debug mode) the exception's 'message' argument. It's certainly not the responsibility of the code that discovers an inconsistency necessitating a 4xx or 5xx error to style it: the error is rarely the main purpose of the function; it's just something the function wants to get rid of as quickly as possible. If the view really wants to RETURN a 4xx or 5xx condition, it can set 'request.response_status_int' the normal way rather than invoking HTTPException. Or it can instantiate the exception and pass it to an application-making function that would turn it into a WSGI application (something like the HTTPException constructor), and return that. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
