use Fatal;
Unfortunately, it only works for overridable builtins.
| [reply] |
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.
| [reply]
[d/l]
[select] |
| [reply] |
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....
| [reply]
[d/l]
[select] |
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.
--Dave
Opinions my own; statements of fact may be in error.
| [reply]
[d/l] |
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] |
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. | [reply]
[d/l] |
| [reply] |
