Colin Fox
cfox at cfconsulting.ca
Sun Mar 14 13:57:18 EST 2004
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Stephens wrote: | |>Raising an exception gives me the control I want, it's just that it |>feels wierd to be doing that as a normal exit, rather than a problem exit. | | | Yeah, it is very weird. I'm surprised it's working for you. Maybe | I'm missing something about your requirements or architecture. Well, what I'm looking for is actually quite simple. If you write your own handler instead of using the mod_python.publisher, you get handed an unprocessed req object, and you respond by returning an apache return code. This is great. The problem is, your single handler gets executed regardless of where in the tree you are. So, if in your .htaccess file you say: PythonHandler myhandler .py and if you try to execute: http://localhost/test1.py and http://localhost/folder/test2.py then your 'myhandler.py' module gets executed for both test1.py and test2.py. I want to be able to have .py files all over my hierarchy that get executed, rather than a single handler. To do that, I have to use mod_python.publisher. However, if I use mod_python.publisher, then I no longer return an apache code, I return a string that is to be printed. I don't want to do that - I'll handle that myself. So I want some features of both techniques, and to do that I end up having to end my publisher based calls by raising exceptions. The system is working perfectly now as far as I can tell, I'm just concerned that there may be a performance penalty with raising exceptions like this, or that the system may at some point be changed so that any raised exception will be considered an error, which will cause my stuff to break. | |>I'd just like to be sure that nothing odd is going to happen if I raise |>an exception. Or alternatively, how I could get processing similar to |>what I get if I write my own handler (where you create a handler() |>function and return a success code). | | | Can't you just assume that if no exceptions have been raised, then | everything was successful? Exception handling seems to me to be more | powerful and flexible than return codes. As I said - *I'M* the one raising the exception, to get the behaviour I need. It has nothing to do with me assuming what an exception means if someone else raises it. | I think you may be over-complicating things a bit. I'd recommend that | you continue using publisher and factor out how you want each request | to get handled into a method or class. Here's just one way: | | | class Page: | | def __call__(self, req): | try: | return self.get_contents(req) | except: | pass # your exception handling code here | | | class IndexPage: | | def get_contents(self, req): | # This would be where you could put | # your current handler stuff | | | index = IndexPage | about_us = AboutPage | ... | I'm not quite sure what you're illustrating here - the Page class isn't used or referenced - is Page supposed to be derived from IndexPage? Or vice versa? And I'm not concerned with HANDLING exceptions, I'm concerned with what happens to the rest of the mod_python system state if I THROW exceptions under normal circumstances. Zope, for example, will execute a database rollback if you raise an exception. I don't want that kind of thing being added on behind the scenes. | | Hope it helps and that I didn't misunderstand you completely :) | | | Best regards, | Erik It's funny, but what I need is pretty simple, but the more I explain it the more it seems to get complicated. I think the best thing is for me to simply publish what I'm doing, and point to it so everyone can see in context what I'm doing. I'll put proper copyright attributions on my files and do just that. cf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVNU9oaQ1/feGlJoRAjRZAJwLjeEmoxFC5+f1CSa4OCZx1f7rKQCeNVyK w7RwcMbPAqjErlpOF85992M= =xi9V -----END PGP SIGNATURE-----
|