Sub::Uplevel installs a CORE::GLOBAL::caller subroutine with a prototype that matches CORE::caller. Contextual::Return's CORE::GLOBAL::caller replacement has no prototype -- which is what causes the error if Contextual::Return loads after Sub::Uplevel.

I suspect you could load just Contextual::Return instead of your entire module before Test::Exception and it would work -- I guess replacing an unprototyped function with a prototyped one is not considered an error.

In my view, it's a bug in Contextual::Return, since you want to have the same caller() semantics as without a CORE::GLOBAL::caller override.

my $caller = caller @foo;  # like "scalar @foo"
[download]

Yes, prototypes are evil, but core functions do have them, so CORE::GLOBAL replacements should have them as well for consistency.

Unfortunately the problem is not unique to your situation nor to only C::R and S::U. There probably isn't a perl programmer who hasn't struggled with omissions in one or more modules. On a larger scale, any engineer struggles with interoperability of parts.

In my life as an EE I made daily decisions such as: "A and B don't work together, do I, keep A and abandon B, keep B and abandon A, or do I modify the circuit to establish de-coupling between the parts." The most important criteria often lay in whether the respective vendors were co-operative in resolving problems. This co-operation, unfortunately, usually depended on the size of our business with the vendor.

Experienced designers knew, if you designed too many wis-bang parts into the design, these interdependencies would kill your project, or your health. So we had rules to avoid this situation. "Use only parts with multiple sources." "Don't use 'wis-bang' parts." "Avoid 'single-product' vendors." and important for the OP "Use only one 'wis-bang' part per design and surround it with 'jelly-bean' parts. The idea behind these was to prefer parts that had cross-licenses agreement between vendors and thus a stable interface specification. It also assured that vendors were competing on price and reputation, thus ensuring their interest in interoperability. The last rule ensured that problems were isolated to one vendor with which you, hopefully, had some clout.

FOSS has only a loose coupling between vendor and customer. The writer of a module often has no financial interest in the success of his code. Thus we rely exclusively on reputation to encourage vendor interest. ( And that's not a very big stick. )

The conclusion to all of this is that we have little control over the interoperability of the modules we choose. Including multiple modules without research and testing will assuredly result in interoperability problems. We need to choose carefully and to shun modules that are too tightly coupled to the core or too each other. We have to choose modules with responsive authors and/or large user bases. Authors here often admonish us to "Don't reinvent the wheel." This is good advice but there is also a valid need for decoupling pulling us in the other direction. We need to also admonish others to: "Pick only tested modules with proven track records." "Use only one 'wis-bang' module per design." "Check for and avoid close module coupling." "Avoid modules from unresponsive authors."

I know these assertions are going to get me into trouble, web forums having a low tolerance for assertions, but I think we need to promote some standard cautions to temper the standard "Don't reinvent the wheel." admonition.

0.27
    -   Patch to fix my broken code with the now working Sub::Uplevel.
+ Many
        thanks to David Golden
[download]