Should I EVER use " || die "?

[usenet]

It seems there are many opportunities to write bad code such as this:

open $file || die $!;

where the || binds too tightly... Perl thinks I mean "open ($file ||
die)" instead of "open($file) || die".

Of course, I can avoid such misunderstandings by always putting my
argument in parens, or by using lower priority "or".

So I got to thinking... maybe I should always use "or die" and NEVER
use "|| die". Yet, I often see the "|| die" syntax - this seems to be
the "usual" programming practice in Perl, so I wonder if I'm missing
some beneficial behavior of "|| die" and if my idea to always use "or
die" is ill-advised.

Thanks.

 

[Uri Guttman]

u> It seems there are many opportunities to write bad code such as this:
u> open $file || die $!;

u> where the || binds too tightly... Perl thinks I mean "open ($file ||
u> die)" instead of "open($file) || die".

u> So I got to thinking... maybe I should always use "or die" and NEVER
u> use "|| die". Yet, I often see the "|| die" syntax - this seems to be
u> the "usual" programming practice in Perl, so I wonder if I'm missing
u> some beneficial behavior of "|| die" and if my idea to always use "or
u> die" is ill-advised.

a good rule of thumb (from peter scott) is:

use named boolean ops (or, and) when doing flow control
use symbolic boolean ops (||, &&) when doing expressions

it works out very well with their different bindings and it also works
well with their readability.

$foo ||= 'zzz' ;

$foo = $bar || 'zzz' ;

open my $foo, 'foo' or die 'bar' ;

/foo/ or next ;
/bar/ and last ;

if( $foo || $bar )

uri

 

[Dr.Ruud]

(e-mail address removed) schreef:

It seems there are many opportunities to write bad code such as this:

open $file || die $!;

where the || binds too tightly... Perl thinks I mean "open ($file ||
die)" instead of "open($file) || die".

Tests like the following have helped me:

perl -MO=Deparse -e '
open $f1 || die ;
open($f2 || die);
open($f3) || die ;
open $f4 or die ;
open($f5 or die);
open($f6) or die ;
'

 

[Tad McClellan]

So I got to thinking... maybe I should always use "or die" and NEVER
use "|| die". Yet, I often see the "|| die" syntax -

My guess is that you look at too much code written by
crufty old timers.

I learned "|| die" when I was learning Perl, because that's all
there was then. Some habits die() hard.


It took years, but I'm now an "or die" kind of guy.

 

[Brad Baxter]

It seems there are many opportunities to write bad code such as this:

open $file || die $!;

where the || binds too tightly... Perl thinks I mean "open ($file ||
die)" instead of "open($file) || die".

Of course, I can avoid such misunderstandings by always putting my
argument in parens, or by using lower priority "or".

So I got to thinking... maybe I should always use "or die" and NEVER
use "|| die". Yet, I often see the "|| die" syntax - this seems to be
the "usual" programming practice in Perl, so I wonder if I'm missing
some beneficial behavior of "|| die" and if my idea to always use "or
die" is ill-advised.

Never say never. Perhaps a side issue, but one situation that has
bitten me more than once, even though I should know better by now:

From: http://www.perl.com/doc/FMTEYEWTK/style/slide11.html

@info = stat($file) || die; # oops, scalar sense of stat!
@info = stat($file) or die; # better, now @info gets its due

Although for me it is usually:

my @x = $cgi->param('x') || 1; # Uh, no.

 

[usenet]

a good rule of thumb (from peter scott) is:

use named boolean ops (or, and) when doing flow control
use symbolic boolean ops (||, &&) when doing expressions

Thanks, Uri, for passing that along - that seems wise and cogent
advice.

Under these guidelines, then, it seems that the answer to my question
(should I EVER use '|| die?') would be 'NO' because (I believe) die()
is ALWAYS a flow-control statement. It might be used within an
expression, but only to perform flow-control if some aspect of the
expression is fatal.

The odd thing is that I don't recall Damian mentioning this, but I
don't have my copy of _PBP_ at hand to check. If Peter's advice is
sound then, IMHO, this is a "best practice" of Perl programming.

 

[Uri Guttman]

u> The odd thing is that I don't recall Damian mentioning this, but I
u> don't have my copy of _PBP_ at hand to check. If Peter's advice is
u> sound then, IMHO, this is a "best practice" of Perl programming.

he alludes to it on page 70, low precedence operators but doesn't say
that exact rule. and since peter and damian are friends and peter and i
both were both on the tech edit team for PBP, i would say this rule is
'sound'. in any case as PBP says, you choose your own rules, just be
consistant. this rule fits my world just fine. and i can always break it
if i have a good reason to or i can use () as desired.

the main point is to know the precedence differences and why both sets
of boolean ops are there and the reasons to use one over the other.

uri

 

[Peter Scott]

Thanks, Uri, for passing that along - that seems wise and cogent
advice.

Under these guidelines, then, it seems that the answer to my question
(should I EVER use '|| die?') would be 'NO' because (I believe) die()
is ALWAYS a flow-control statement. It might be used within an
expression, but only to perform flow-control if some aspect of the
expression is fatal.

Like most heuristics, it's not a 100% rule. It derives its usefulness
from the desire to reduce the number of necessary parentheses. The more
most people program in Perl, the less they want to use parentheses when
they don't have to.

open $fh, '<', "foo" || die $!

won't work without more parens. The same applies to

open $fh, '<', $fname or $default_fname

.. The heuristic leads to a better choice in these cases. But there
again, a few days ago I wrote something roughly equivalent to

$pick = int rand get_max_num() || die "No range for choosing"

But many people wouldn't like that. YMMV. And TMTOWTDI.

The odd thing is that I don't recall Damian mentioning this, but I
don't have my copy of _PBP_ at hand to check. If Peter's advice is
sound then, IMHO, this is a "best practice" of Perl programming.

Damian doesn't cover every conceivable best practice, no one could.
There's still additional ground covered by books like my Perl Medic (which
isn't a 'best practice' book per se anyway).