IO::File is only involved if you use HANDLE->print(...), not for print(HANDLE ...), much less before the handle is even created by open. It's not relevant here.

Contrary to what you said, subs works fine.

use strict;
use warnings;
use subs qw( open );
use Errno qw( EPIPE );

sub open {
   $! = EPIPE;
   return 0;
}

open(my $fh, '<', \my $buf) or die("open: $!\n");
[download]

open: Broken pipe
[download]

Update: You probably want to test a module without changing it, so your code would look more like the following:

package ModuleToTest;

sub f {
   open(my $fh, '<', \my $buf) or die("open: $!\n");
}

1;
[download]

use Test::More tests => 1;

{
   package ModuleToTest;
   use subs qw( open );
   use Errno qw( EPIPE );
   sub open {
      $! = EPIPE;
      return 0;
   }
}

use Module;

ok( !eval { Module->f(); 1 } );
[download]

1..1
ok 1
[download]

If I understand your program correctly somehow you're trying to get a file name from get_string() method and then open it, so far so good, but in the open call you are passing a reference to an scalar that is an in-memory file ( as mentioned here ) that means that if you read STDIN you will get $string's contents. In this scenario open will never fail as there no way you can have a problem opening an in-memory file.

So if you meant to get a filename from an get_string() and open it you have to take out the "\" and if file cannot be opened will fail for sure

my $file = '/tmp/inexistent';
open( my $fh, "<", \$file) or print "open in-memory file error";
open( my $fh1, "<", $file) or print "open real file error ";
[download]

Ikegami, I tried subs again. It's pretty close to what I had tried before, but I was trying explicitly to be as close as possible to what you suggest. The script hangs on the print/read statement without the custom "open" function running.

bluescreen I arrived at this situation by trying to follow best practices. 1.) opening a file should be error checked. 2.) I should use Devel::Cover to make sure that my tests provide 100% test coverage. It does seem likely that this particular call can never fail, but I still thinking the problem would be hard in some other circumstances. Also may be there could be a security hole in the perl core, which would allow hackers to generate such a situation and I want to defend my code against such known unknowns.

Actually I have had two more ideas on how to approach this. One is experimenting with

local *IO::File::open = sub {.....}
[download]

Edit: Looking at the code for subs I can see why it won't work for me. It only deals with the calling package not where as I want to change how "open" works inside a package from outside.

Edit 2: My experimentation with typeglobs is failing. It does no better than the subs code above.

Although I agree that you should try to get a good coverage I wouldn't pursuit the 100% itself. Let's consider the following subroutine

sub divide {
    my ($a, $b) = @_;
    return $a / $b;
}
[download]

You can easily create a test case and get a 100% coverage, and as you might realized the code can still fail ( if $b is 0 you'll get a "Illegal division..." ), here the 100% gives you a false sense of security. On the other hand the more tests your application has the harder it is to change it or refactor it

My point is you shouldn't blindly follow best practices, they are just a guide not a law (use your own criteria). Don't use test coverage as a goal itself, otherwise you would end up writing code to get 100% coverage instead of writing code to perform a task

On the other hand the more tests your application has the harder it is to ... refactor it

On the contrary, the more tests you have (or rather, the better your test coverage), the *easier* it is to refactor. Refactoring should involve no changes to the code's function, and the better your test coverage, the easier it is to rearrange the code without unwittingly breaking it.

bluescreen, I absolutely understand where you are coming from on 100% test coverage. It may be fairer to say I am experimenting with it. I have all sorts of thoughts on the subject. For a start with a new module it is straightforward, to keep the test coverage up to 100%. For an older module you can only hope to approach it aggressively. It is interesting to take a module that you regard as critical, and run Devel::Cover on it - and to compare the results with the bug list - and to ask how many of those bugs could have been avoided with better testing. When I have done that and tried to discuss the results, the responses such as they were struck me as complacent. Also I am working on restructuring and improving CGI::Application::Plugin::Authentication. As a I did not write that module originally, getting the test coverage up seems a constructive way of knowing and controlling the impact of my changes.

You declare main::open (use subs qw(open);), and you define main::open, neither of which has any effect on calls to open in Test::. See the example I added to my post 8 hours before you posted for how to replace builtin open in a module without changing he module.