Re^3: Error: Attempt to reload module.. while testing failing require

[haukex]

So i have no chanche at all to make the require or use to fail (in the right, intended way, aka leaving %INC clean)?

That depends on what you're testing. You can override require (e.g. BEGIN { *CORE::GLOBAL::require = sub { ... } }, newer versions of Perl required), point require at a different file that returns a false value, or, if you really wanted to, you could put a return; in Win32::Backup::Robocopy (because simplifying a lot, use is require is do is eval, and you can return from the latter two). However, I wouldn't recommend that, because having a bare return in the main code of module is IMO quite unusual, and in a normal Perl script would cause an "Can't return outside a subroutine" error. If what you are testing is the behavior of Win32::Backup::Robocopy, then I'd only consider two options realistic: it dieing, or it succeeding. To test that, yes, you will have to delete from %INC to get require to reload the module - but actually, I'd recommend the solutions I suggested above instead.

the our solution: are not to avoid these in modules?

I don't see why not? IMHO it's fine to use them in the way I showed, it allows setting a global default while still giving the user per-object control via a new argument. If a package variable was the only way to set a module's option, then yes, I'd agree that's not the best design choice, since users would have to use local or risk action-at-a-distance. But in some cases, some defaults really are global - just one example, in my File::Replace, I have a $File::Replace::DISABLE_CHMOD global, which can be set in the case that the system doesn't support chmod (but it can still be set on a per-object basis).

definetively I have to die or croack if what is set in %ENV is invalid.

Hm, I think I understand, you want to let the user know if what they set in %ENV is invalid? I think it's a design choice at which point you do that and whyhow. For example, if $ENV{PERL_ROBOCOPY_EXE} contains an invalid location, but a valid location is passed to new, is that really a fatal error? TIMTOWTDI, but I might consider just issuing a warning when Win32::Backup::Robocopy is loaded with a bad $ENV{PERL_ROBOCOPY_EXE} setting.