http://www.perlmonks.org?node_id=1082910


in reply to Re: The 'eval "require $module; 1"' idiom
in thread The 'eval "require $module; 1"' idiom

I generally consider it to be cargo cult.

I intentionally put the "; 1" into this exact construct not out of some worship of practices that I have observed and not understood.

I put the "; 1" to show that I am explicitly checking for whether or not the code inside of the eval dies.

To a lesser extent, I also do it just to short-circuit the reader having to contemplate if there are any ways where require could not die but also not return a true value. I believe that the 'die' behavior of require is quite well understood.

However, the return value from require is almost never used. It isn't even really documented. You can infer likely return value behavior from Perl code included in the require documentation but that code is marked "Has semantics similar to the following subroutine:" (emphasis added), so such conclusions seem wise to treat with a certain level of skepticism.

The primary interface for require is that it loads the module or it dies. So it makes sense to use a construct that tests for whether or not the require died. That is what the "; 1" does. Leaving off the "; 1" requires the reader to try to find and understand information about a bit of behavior that is nearly useless and is poorly documented. That is not an improvement.

- tye        

  • Comment on Re^2: The 'eval "require $module; 1"' idiom (intended)

Replies are listed 'Best First'.
Re^3: The 'eval "require $module; 1"' idiom (intended)
by davido (Cardinal) on Apr 19, 2014 at 20:03 UTC

    ++

    ...which is why, as an idiom, it's wise to disconnect the success flag from the return value of the thing_that_may_fail(). I'm glad I'm not alone in seeing merit in the clarity that comes from decoupling the thing that may fail from the idiom that tests it.

    The point to "eval "possible_failure(); 1"" is that we're not concerned with possible_failure()'s return value, we're concerned whether or not it threw an exception. We shouldn't have to look up and infer what its return value will be, we should simply test whether it threw an exception or not. That's where 1;" or warn "Woops!"; comes in.


    Dave