Trapping a Function Call in Non-OO Perl

kakaze has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

This may be a mad idea but I'm wondering if there is any to trap a function called from a require'd file?

There is a require file I want to use (in order not to have to duplicate most of the code in another file) but on error, the main function called in the file calls another exit function. I want to handle the error condition myself while bypassing the called exit function.

I know I can do method overloading in OOP but we are not using OOP :(

Perhaps it's not possible but I'd like to hear from my fellow monks wisdom!

Thanks in advance,

Kakaze

Comment on Trapping a Function Call in Non-OO Perl

Replies are listed 'Best First'.
Re: Trapping a Function Call in Non-OO Perl by rinceWind (Monsignor) on Feb 15, 2002 at 10:39 UTC
Take a look at Hook::LexWrap You don't need to worry too much about the scary internals of this module to use it	[reply]
Re: Trapping a Function Call in Non-OO Perl by talexb (Chancellor) on Feb 15, 2002 at 12:02 UTC
Without getting into code fragments, the way you could do that would be to change the required file so that it uses a function pointer to point to its own error routine. This function pointer could be repointed to your new module's error-handling function before you start. --t. alex "There was supposed to be an earth-shattering kaboom!" --Marvin the Martian	[reply]
Re: Re: Trapping a Function Call in Non-OO Perl by IlyaM (Parson) on Feb 15, 2002 at 12:07 UTC
Another approach is using exceptions. That is replace exit with die and trap it with eval when needed. -- Ilya Martynov (http://martynov.org/)	[reply]
Re: Trapping a Function Call in Non-OO Perl by dash2 (Hermit) on Feb 15, 2002 at 15:27 UTC
Or, if you can't edit the other file for some reason, you could mess with its symbol table. No need for OO. `OtherPackage::exit_function = MyPackage::do_what_I_want;` [download] dave hj~	[reply] [d/l]
Just cause you can doesn't mean you should! by dragonchild (Archbishop) on Feb 15, 2002 at 15:50 UTC
I would add that this is a MAJOR action, this messing with someone else's symbol table. This is something that should be done as an ultimate last resort, with great trepidation. If you're considering doing this, you should probably just write your own version of said file. The reasoning is this: I can't edit the file I want to edit. This means I probably don't completely comprehend said file. I'm making a change in something the file assumes will not be changed. This means that I don't know what all the ramifications of that are. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]
Thanks for the replies guys! by kakaze (Sexton) on Feb 15, 2002 at 16:40 UTC
So it was not such a mad idea after all :) Some great ideas here, now I just have to figure out which one to apply. BTW, I'd agree wholeheartedly with not messing with the symbol table :) Thanks, Kakaze	[reply]