Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

wishlist: die-on-failure for built-ins

by tlm (Prior)
on Apr 19, 2005 at 00:19 UTC ( #449071=perlquestion: print w/replies, xml ) Need Help??

tlm has asked for the wisdom of the Perl Monks concerning the following question:

There are a whole bunch of functions, such as chdir, open, print, etc., etc., whose return values one should check to make sure they succeeded. (Most Perl programmers I know check the return value of open; some check the return value of chdir; no one checks the return value of print.) This is particularly recommended for functions that perform system calls, such as open or fork.

It would be nice if there was a way to tell perl to die (with an appropriate error message) whenever any of these functions failed. This would not be necessarily good for production code, but I think it would be handy during prototyping and for one-off scripts.

I have not figured out any way to do this simply. The only solution that comes to mind is to override all these functions. Is there a simpler approach?

the lowliest monk

Replies are listed 'Best First'.
Re: wishlist: die-on-failure for built-ins
by Zaxo (Archbishop) on Apr 19, 2005 at 00:22 UTC

    use Fatal;

    Unfortunately, it only works for overridable builtins.

    After Compline,

      Very cool. Thank you!

      I did notice that the docs for Fatal are somewhat off when they say that overridable built-ins can be modified through this module. In fact Fatal can handle only those overridable built-ins foo such that prototype('foo') is defined; there are overridable built-ins for which this is not the case, and therefore will cause Fatal to fail at compile time.

      the lowliest monk

Re: wishlist: die-on-failure for built-ins
by ihb (Deacon) on Apr 20, 2005 at 11:52 UTC

    Sub::Context could perhaps be interesting to mention in this context.


    See perltoc if you don't know which perldoc to read!

Re: wishlist: die-on-failure for built-ins
by Mabooka-Mabooka (Sexton) on Apr 19, 2005 at 04:21 UTC
    I'll try to be very careful not to disturbe piece in the monastery. Intuition tells that this will be a tough errand...

    First of all: why build-ins only? Don't you want all your subs to do the same? And if not - why?

    Second: if what you wish were possible (and easy), that wouldn't work, you'd wish your wish back. Sometimes you want it to die, sometimes - do smth. else. E.g.:
    for each dir ( dirs) # I am using pseudo-code...:-) => if chdir(dir) => do smth. there => else ==> print_warning(couldn't go to dir, skipping) ......

    I think this whole problem is illusive, artificial and leads astray. Even worse; it hides the real problem. The real problem is: having a programming discipline. Monks must know what dicipline means, right? If one dont's check EVERY RESULT OF EVERY SINGLE CALL, whatever is the language, -- well I say (s)he still has a lot to learn.

    Now, the most dangerous part. This ~shouldn't~ have anything to do with Perl. Seems that somehow it does. I'd really like to hear a scientific explanation. My best guess is: "Less typing" is a very popular paradigm among Perl programmers. Historical reasons? philosophical?..

    In other words, a solution:
    die unless chdir($dir);
    doesn't even come to mind. (!!!!!!!)

    Well, less typing won't save you your development time. On the contrary.

    I often see one line of code where I would *automatically* without thinking type six. E.g.: ...
    if kind($matter) == "solid" { dig_it($matter); } eslif kind($matter) == "liquid" { die "We don't support underwater activities yet"; } else { die "RTErr: Unexpected type of matter!";}

    Instead, many people type only the 2nd line, some - 1st and 2nd, more rare - also 3d and 4th, and almost nobody - 5th and 6th.

    Well you know what: those few extra lines save weeks of debugging.
    So from all points of view the answer is very simple: get used to typing more.

    Now, when you get to the discipline to always surround any call with if() or if(!...) or die unless..., only then the question "How to type less?" should be risen. There're plenty of techiques for achieving that...:-).

    PS: Coding for production vs. "prototyping and for one-off scripts" in two different styles is IMHO also a terrible mistake. This way, you'll strep into same traps twice.

    Sorry for such a long and emotional post. Just spent a weekend cleaning up smb. else's mess....
      Second: if what you wish were possible (and easy), that wouldn't work, you'd wish your wish back. Sometimes you want it to die, sometimes - do smth. else.

      I often code things as:

      sub foo { my $error = ...; return $error if (defined wantarray || ! $error); croak "foo failed: $error"; }
      Now you have a choice. If you check the return value (or assign it to undef), then it won't die. If you're lazy and there's an error, then it dies.

      Opinions my own; statements of fact may be in error.
      Fatal provides the error handling if you want it...

      If the symbol :void appears in the import list, then functions named later in that import list raise an exception only when these are called in void context--that is, when their return values are ignored.
Re: wishlist: die-on-failure for built-ins
by DrHyde (Prior) on Apr 19, 2005 at 08:12 UTC
    While I agree that the return values from open() and chdir() should be checked, I can't agree that print() should be checked in the general case. There may be a few special circumstances where you would check it, but if confronted with a load of code saying:
    print "hello world\n" || die "goodbye cruel world\n";
    I think I'd want to strangle the author.

      Typically I don't check print's return value, but there are situations in which it is important to do so. E.g. one approach (described in perlipc) for dealing with PIPE errors is to set $SIG{ PIPE } to 'IGNORE' and detect PIPE errors by checking the return value of print.

      the lowliest monk

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://449071]
Approved by blokhead
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2023-12-11 16:21 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (41 votes). Check out past polls.