Re: wishlist: die-on-failure for built-ins

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)
......
[download]

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);
[download]

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!";}
[download]

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....

Comment on Re: wishlist: die-on-failure for built-ins Select or Download Code

Replies are listed 'Best First'.
Re^2: wishlist: die-on-failure for built-ins by dpuu (Chaplain) on Apr 19, 2005 at 18:22 UTC
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"; }` [download] 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. --Dave Opinions my own; statements of fact may be in error.	[reply] [d/l]
Re^2: wishlist: die-on-failure for built-ins by Transient (Hermit) on Apr 19, 2005 at 18:36 UTC
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.	[reply]


P is for Practical
	PerlMonks