That is my view as well but I am afraid to say that exceptions in python has been expanded into something like normal flow(when you have lots of exceptions, it is no longer exception). And modern language don't have goto which is what is going on here.
The problem with returning signal(or any form of return, even just let the function fall through to the end) is that if there is N decorators, each of them must code into this situation: if redirect: return #let whoever knows how to do it do it, not me else: do the proper decorator stuff Kevin Dangoor wrote: > My general philosophy is that exceptions are for abnormal situations, > not standard control flow. That's a philosophy I've had for several > years. The "raise cherrypy.HTTPRedirect" construct violates that rule, > but is far better than calling a function that sets up a redirect on > one line and returns on another (opening up the possibility of doing > other things instead of returning). > > returning a signal to redirect is a little more pleasant to me, > because it reflects that it's a normal and expected situation. > > By the way, I'm not going to add code to TurboGears to prevent "raise > cherrypy.HTTPRedirect" from working... > > The real question is whether having two ways to do it with the > "return" mechanism considered preferred is better than having one way > to do it. (Actually, I'm guessing that the CherryPy 2.0 way, which is > similar to John Speno's Subway example, is still available in some > form... so there's probably already two ways to do it.) > > So, there's definitely a no vote on that from bonono and a yes vote > from Daniel. > > Kevin > > On 10/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > I would disagree here(I believe we have talk about this before). > > > > return cherrypy.HTTPRedirect. > > > > It looks like two incompatible meaning in one. Do you want to return or > > redirect ? return to me means back to caller and in this case, it could > > very well be decorated. So do I know if some logic is there ? raise > > exception is cleaner to me in this case. > > > > Daniel wrote: > > > > > > Let's think about what the "dosomething" method is doing here--it's > > > creating something to be processed, or short-circuiting to a redirect. > > > IMHO that type of control flow leads to buggy apps because you're never > > > quite sure what to expect when you call a method--the control flow is > > > not explicit (very bad in a complex app). It would be more clear to do > > > it this way: > > > > > > @turbogears.expose() > > > def mypublicmethod(self, arg): > > > try: > > > someval = self.dosomething(arg) > > > except InconsistentStateError: > > > return cherrypy.HTTPRedirect(...) > > > return self.process(someval) > > > > > > def dosomething(self, arg): > > > # oops, something isn't in the right state... > > > raise InconsistentStateError() > > > > > > Again, I think it's important to keep application flow clear and > > > explicit. > > > > > > > -- > Kevin Dangoor > Author of the Zesty News RSS newsreader > > email: [EMAIL PROTECTED] > company: http://www.BlazingThings.com > blog: http://www.BlueSkyOnMars.com
