Ok... I know we all love 'exit;' <G> But with mod_perl we need to learn new tricks.
We also have been told "globals are bad" yet, certain models, such as links SQL, show that "global objects" can be a "good thing" and we keep scratch variables local. Make an object, put all the related data into that object, and keep track of your object. Makes good sense.
My question has to do with that "exit;" problem :)
Returning to main; is what we want to do, then fall off the end of the script. That allows the program to gracefully end, and not remove itself from memory, so it's ready for the next set of "data".
But, let's say we have several subroutines, and we want to keep the logic of code clean, by putting each of a number of actions into their own subroutine. We also don't want to use exit; since that would require the re-load/compile of the program, and we lose mod_perl benefits.
&sub1
&sub2
&sub3.
Now, what we want to do is have main; call one of each of the various segments in turn, and what each sub1 does is further pass it on, and so on.
Now we are at sub3. We hit an "error" or "exit" condition, and we want to stop what we are doing and quit. This can be displaying the appropriate page, or finding out what we are doing is bad, and we need to break out of that level back up 2 levels. or even 3 levels.
It used to be as easy as:
print error warning && exit;
But, that was then, this is now.
One thing I did was create an $ERROR_COND variable (or object) but that seemed way too messy. And it got messy. A whole program (or at least object) could be devoted to tracking the error flags.
Since most of my subs operate on the object, and don't return a value directly, I've tried doing:
&go_to_sub() || return;
Where the last line of the sub routine is a return(1) and any error condition in the sub routine returns return(0).
That has problems too, but it seems to work. At least two levels deep. Three levels deep, ie: the level the return; returns to above, has to be ready to handle any condition, good or bad, passed to it.
Is there a mechanism that functions the way we'd expect -- to end processing of the program, and "exit;" in a mod_perlish fashion, or is it really a matter of bubbling back up through each of the levels?
Books are surprisingly thin on this issue... either because everyone is supposed to understand it, or I am asking the wrong question <G>
It just seems that adding (literally) hundreds of checks for the $ERROR_COND object, adds loads of overhead and CPU effort to replace the simple 'exit;'
The number of error/exit conditions is high enough (with user data) that using 'exit;' in a mod_perl environment would eliminate almost all the benefits. I'm looking for an elegant way to handle this -- if there is one -- since it's this script that will be taking on most of the challenges from the users.
BTW: I'm putting this here rather than the perl forum, because I'm looking for answers more specific to Links SQL then general perl/mod_perl, if possible. I've only just begun to figure out what the various modules do, and there might be an error handling object in there somewhere <G>
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
We also have been told "globals are bad" yet, certain models, such as links SQL, show that "global objects" can be a "good thing" and we keep scratch variables local. Make an object, put all the related data into that object, and keep track of your object. Makes good sense.
My question has to do with that "exit;" problem :)
Returning to main; is what we want to do, then fall off the end of the script. That allows the program to gracefully end, and not remove itself from memory, so it's ready for the next set of "data".
But, let's say we have several subroutines, and we want to keep the logic of code clean, by putting each of a number of actions into their own subroutine. We also don't want to use exit; since that would require the re-load/compile of the program, and we lose mod_perl benefits.
Code:
main; &sub1
&sub2
&sub3
Now, what we want to do is have main; call one of each of the various segments in turn, and what each sub1 does is further pass it on, and so on.
Now we are at sub3. We hit an "error" or "exit" condition, and we want to stop what we are doing and quit. This can be displaying the appropriate page, or finding out what we are doing is bad, and we need to break out of that level back up 2 levels. or even 3 levels.
It used to be as easy as:
print error warning && exit;
But, that was then, this is now.
One thing I did was create an $ERROR_COND variable (or object) but that seemed way too messy. And it got messy. A whole program (or at least object) could be devoted to tracking the error flags.
Since most of my subs operate on the object, and don't return a value directly, I've tried doing:
&go_to_sub() || return;
Where the last line of the sub routine is a return(1) and any error condition in the sub routine returns return(0).
That has problems too, but it seems to work. At least two levels deep. Three levels deep, ie: the level the return; returns to above, has to be ready to handle any condition, good or bad, passed to it.
Is there a mechanism that functions the way we'd expect -- to end processing of the program, and "exit;" in a mod_perlish fashion, or is it really a matter of bubbling back up through each of the levels?
Books are surprisingly thin on this issue... either because everyone is supposed to understand it, or I am asking the wrong question <G>
It just seems that adding (literally) hundreds of checks for the $ERROR_COND object, adds loads of overhead and CPU effort to replace the simple 'exit;'
The number of error/exit conditions is high enough (with user data) that using 'exit;' in a mod_perl environment would eliminate almost all the benefits. I'm looking for an elegant way to handle this -- if there is one -- since it's this script that will be taking on most of the challenges from the users.
BTW: I'm putting this here rather than the perl forum, because I'm looking for answers more specific to Links SQL then general perl/mod_perl, if possible. I've only just begun to figure out what the various modules do, and there might be an error handling object in there somewhere <G>
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ