Howdy!
Apologies if this post sounds too "absolutist", but I see this as an
issue that was resolved many years ago.
The way I see it there are three options:
:: Raise an exception from a pool of available exceptions.
:: Return an object, possibly an instance of something.
:: Execute a function which either internally re-routes or raises an exception.
Let's examine the pros/cons of each, in reverse order. First, functions:
+ Simple to document.
+ Simple to use.
- Non-obvious. Developers have to be fluent in HTTP status codes.
- Difficult to customize. (Middleware or API.)
- Magic; only core developers sure what really goes on inside.
- If handled using exceptions internally it arbitrarily increases the stack.
- AKA "Should just use the damn exceptions directly." ;)
- Likely complicated to implement. (PEP-20)
Returns:
~ Not entirely sure what the benefit(s) would be.
- Multiple objects to document.
- Possibly multiple calling syntaxes (e.g. notfound, Redirect(foo))
- Have to manually handle if returned from a nested call.
Exceptions:
+ Bubbles, so no return value checking.
+ Already fully documented and well implemented as part of WebOb.
+ Easily customizable through subclassing.
+ Somewhat self-documenting via the exception names.
- Magic to new developers unfamiliar with exceptions.
On 2011-05-16 11:42:11 -0700, Stephen Lacy said:
"There should be one-- and preferably only one --obvious way to do it."
Amen.
In general, I find the "returns or raises" pattern to be a fairly weird
design. I'm not fond of thinking of things like access violations as
"exceptions".
Think of it this way: if it walks like an exception (you want it to
bubble), talks like an exception (the vast majority of HTTP status
codes are in the 4xx and 5xx range; errors), then it should probably be
an exception. Your application has reached an exceptional (non-200)
state. ;)
I'd like to be able to read my view function and know exactly what HTTP
return codes are going to be produced.
It's a fairly simple project-wide, module-wide, or function/method-wide
search: "raise HTTP".
When some function way down the call stack can raise up an arbitrary
exception from httpexceptions, it makes it really unclear what my view
is going to actually do.
Well, the general policy for exceptions are handle the ones you expect
and pass along the ones you don't. (E.g. a bare "except:" block is
bad, bad mojo.) I'd consider that true even for 3xx, 4xx, and 5xx
status codes. Additionally, that's what finally: and else: blocks are
for.
The possible exceptions a reusable block of code can raise should be
part of the documentation of that code the same as the argspec or
expected return values are.
— Alice.
--
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.
