in reply to Upgrade-proofing overridden subroutines
I can imagine circumstances where Broken::Module might not always be broken - say that Broken::Module::foo only fails some times. It may be that you (the user of Broken::Module) can identify when this happens, and provide test cases and workaround logic in the application.
If Broken::Module::foo is idempotent in intention and in implementation (i.e. you can call it as many times as you want with no side effects), it would make sense to call the real Broken::Module::foo first, and detect the exception or bad return value, and only then call the workaround code. Obviously this wouldn't work if Broken::Module::foo is transactional in nature.
Just a thought
--
Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
|
|---|