I'm quite happy for it to blow up in their face.

So, what purpose does your module serve?

In some wholly arbitrary subset of cases, it allows your users to avoid faulting; but in other, equally likely cases it doesn't.

And what does that mean for the callers of the modules that use your module?

It means that for some failures, instead of detecting all possible errors by trapping exceptions like this:

eval {
    funcThatPassesAFileHandleOrName( $arg );
} or do_something();
[download]

They now have to do something like:

eval {
    unless( funcThatPassesAFileHandleOrName( $arg ) ) {
        doSomething();
    }
} or doSomething();
[download]

They can't omit the eval because -- as you've just admitted -- there are some common cases that you simply make no attempt to catch.

And what do they -- the users of modules that use your module to validate these parameters -- gain from its use? That is, what action can they take in that arbitrary subset of cases where your module detects an error that would normally raise an exception?

Can they -- at runtime -- invent a different filename that is valid? Or pluck a different filehandle out of the air that passes the test and use that instead?

No. All they can do is either issue a warning and move onto the next filehandle -- assuming that is the logic of the program -- or they can die with an error message. But does your module report enough information to allow them to report why it failed? Illegal filename; or file doesn't exist; or file is protected against them; or the filehandle was real, but has been closed; or was never opened; or ... ??? No. All they can do is issue some vague "something was wrong" message.

Whereas, if the called module has just gone ahead and attempted to use the argument as passed for whatever IO operation it was destined, the runtime would have detected the problem and raised an exception containing a very clear error value/string that would actually help the user.

And if the logic of the program was such that it could continue (say; with the next file(handle)), then the user's eval -- that he will still need to employ anyway -- would have both caught it and provided the precise error message to the caller for logging.

All your module does is convert a subset of useful exceptions into a vague and non-descriptive boolean false!

The net result is more complexity for less than no gain.

Your module is there, and nothing I say will cause it to un-exist. There is no reason for you to continue to defend its existence. But maybe my missive here will cause a few readers to consider thinking through the purpose of their modules to their logical conclusions, rather than being so quick off the mark to throw something together and whack it up on CPAN.

CPAN's greatest limitations are a) its size; b) its quality. Finding the good stuff amongst the ill-thought through, gets harder every day,

Width is no substitute for quality.