Hi Kevin, I think that philosophically, you might be correct, but from a practical point of view, to me at least, raise is a very clear indicator of a change in program flow and the work Redirect in the exception makes it clear what is happening.
Also, and I think this has been mentioned before, even in the standard library, exceptions are used for program flow. Iterators, for example, raise an exception when they hit the end of whatever they are looping over. That's not an exceptional situation. Eventually an iterator WILL end (in most cases). So it is just a normal part of it's program flow. There is also the issue of having too many ways to do it (a.k.a. Perl-itis). I think that it is a stronger argument to have one, obvious way to do it (Python philosophy), than it is to have the most "pure" way to do it (Java-itis). I guess what I am saying is that CherryPy already has a way to handle it, and it is not completely horrible. Why add extra code (more moving parts = more things that can break) just for program flow conceptual purity. Like I said, conceptually, you are probably right, but there is definitely a value to KISS. (And keeping the differences between TG and it's base components to a minimum.) Just my $0.02. Hope it provides food for thought. Krys 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 > > >
