On Wed, 2011-06-01 at 11:34 -0700, Mike Orr wrote:
> On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
> <[email protected]> wrote:
> > Hi,
> >
> > This post totally went over my head and there's a lot to read which I
> > don't feel like doing right now, so I'll just give my 2 cent straight
> > away (and if it was already addressed, reply "already addressed", and
> > I will dig into the thread's archives):
> >
> > 2011/5/15 Chris McDonough <[email protected]>:
> >> def aview(request):
> >> abort(401)
> >>
> >> def aview(request):
> >> redirect('http://example.com')
> >
> > What I *really* didn't like with Pylons abort() and redirect() was the
> > fact that that these functions were stopping the code flow without a
> > return statement.
>
> We could just make abort() and redirect() helper functions that return
> an exception, which the user would then raise. The priority for me is:
>
> 1. Make HTTPExceptions raisable by default.
FTR, HTTPExceptions are and always have been raisable, they're just not
currently caught by default. Sorry if making that distinction sounds a
bit pedantic, but important because this is exactly what a developer
needs to do in order to catch and display them currently:
from pyramid.httpexceptions import HTTPException
config.add_view(lambda context, request: context,
context=HTTPException)
In other words, the argument boils down to whether to make people add
the above to their application configuration or whether Pyramid does it
on their behalf by default.
> #1 is important so that you can cut through multiple function calls
if
> you discover an error condition.
> Use case 1: a support method/function for several handlers
> discovers a required query parameter is missing. The application's
> forms and links would never produce such a request, so we presume the
> request is illegitimate and abort 400.
> Use case 2: a support method/function discovers that a required
> support file is missing, an authentication server is unreachable, etc.
> This is a webmaster/sysadmin error so we abort 500.
>
The folks I've talked to on the "don't turn HTTPExceptions into
responses by default" side of the debate argue that both use cases above
are poor coding practices because only "view code" (code that is
contacted only because a view was matched, as opposed to random things
that that view may call into) has enough information to be able to
return a sensible response. They further argue that since it's so easy
to "turn on" the feature, allowing folks that don't share their opinion
to do it, Pyramid shouldn't do it by default. Just FYI, that's the
other side of the argument.
IMO, all the other stuff (#2 thru 4) depends on this decision, and is
therefore detail-y ancillary stuff.
- C
> #2 is important because HTTPFound is not very self-documenting, and we
> shouldn't have to specify the location by keyword argument since it's
> the entire purpose of the call.
>
> #3 is useful but perhaps not necessary. It's convenient but not
> necessary self-documenting because you have to memorize all the
> numbers. It's also helpful to have a message as a positional argument.
> This would be added to the error message. This has been proven useful
> in Pylons. A further enhancement would be to have both a secure and an
> insecure message. The secure message would appear in the default error
> screen, while the insecure message would be included in the sysadmin's
> error report.
>
> #4 is minimally useful. They do have the significant downside of
> looking like returning function calls when they actually change the
> program flow. It would be fine if they simply return the error and the
> user raise it explicitly.
> raise redirect(location)
> raise abort(N, message=None)
>
> Or they could be capitalized to appear more like class constructors:
> raise Redirect(location)
> raise Abort(N, message=None)
>
> --
> Mike Orr <[email protected]>
>
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
