Re: What's the opposite of // (err) operator?

The implication is that wittingly or unwittingly you want undef to be the only false value. I think that is the higher priority anomaly to address in your story. With Perl it is far more viable to enforce a regime of true=ok false=not ok and use boolean logic rather than testing for defined() or specific values, with some exceptions such as testing for the presence of keys/indexes in hashes/arrays or managing return codes from external programs or scripts. So in the given example I would expect to deal with it much more simply from where $x goes wrong e.g.:

$x = ...
   or return;
[download]

But if say $x == 0 is okay for continuing, then:

defined( $x = ... )
   or return;
[download]

I can conceive of returning undef explicitly in some cases but if you are deviating too often from "statement or return" simplicity then it's your boolean logic management that really needs simplifying rather than addressing the symptoms in the form of more complex value logic.

One world, one people

Comment on Re: What's the opposite of // (err) operator? Select or Download Code

Replies are listed 'Best First'.
Re^2: What's the opposite of // (err) operator? by John M. Dlugosz (Monsignor) on May 12, 2011 at 06:24 UTC
No, I know to use Perl boolean rather than tests against actual values. In the case at hand, I really want undef to stop subsequent work on the value. It's more like a database NULL, rather than a value of 0 (or an empty string). Maybe both of those are allowed values that I want to operate on.	[reply]
Re^3: What's the opposite of // (err) operator? by anonymized user 468275 (Curate) on May 12, 2011 at 13:42 UTC
Problem with that is that NULL ( =undef() ) lacks even quasi-tautology as a test for mechanistic failure. I'd be inclined to keep the return value strictly for that and use references or instance subvariables to pass the actual database values between routines. DBI (to the extent I use it) sticks to these basic principles. If another required module doesn't, I'd use inheritance into a fairly trivial class that performs the separation between value logic and mechanistic logic for any "misbehaving" methods, rather than look for a way to do that throughout my higher level code. One world, one people	[reply]