On 11/28/06, JupiterHost.Net <[EMAIL PROTECTED]> wrote:
But if you could do this:
return_carp(...) if $whatever;
the first time around then you could have 10000 places it gets used in
your app and still only change it in one place. And its pretty
unambiguous IMHO.
Next imagine the stamp it gets is changed format, again you need to find
and update 100 (or are there more now than there where a few weeks ago
when you first added the stamp?) places instead of one which addresses
all concerns :)
So any ideas about how to get:
goto &CORE::return;
to work like it reads.
The suggestions you were given do exactly what you ask for. Obviously,
read 'goto &CORE::return()' differently from the rest of the list. So
instead of complaining, why don't you explain how you read it, instead
of simply repeating "work like it reads"?
I *think* this is what you want to do, although since you haven't
actually said yet, it's hard to tell:
When an error occurs in a subroutine, you want to call another
subroutine (e.g. log()) and then exit that second subroutine in such a
way the the first exits as well. You haven't said what status you want
the first sub to exit with, but we'll assume (since you haven't said)
that you want it to be status of the second.
The "normal" Perl idoms for that would be:
sub my_sub {
my $err = something_went_wrong() ? 'this is bad' : undef;
return return_carp($err) if $err;
}
sub return_carp {
my $error = shift;
# do your logging
return;
}
No muss, no fuss. You put your general routine in return_carp() and
the pass the specific data for each of your '1000 places' in as a
[variable|reference|bareword|whathaveyou].
And that's assuming I'm guessing correctly; your test case, as many
people pointed out, condenses quite simply to:
my_carp($err) && return if $err;
or even:
$err && my_carp($err) && return;
# or if you want the return value:
$err && return my_carp($err);
That may not be quite a succinct as what you're hoping for, but it's
certainly not much typing, particularly in the last form.
As for 'goto &CORE::return', I suggest you take a swing through
perldoc -f goto. 'goto &sub' expects, well, a subroutine. You're
passing it a function call. You tell us how you expect system
internals to behave when they're passed the wrong argument type, and
we'll help you emulate that bahaviour.
Actually, here's my nomination for getting 'goto &CORE::return' to
"work like it reads":
die "Goto undefined subroutine &CORE::return\n" if $whatever;
Even if it worked the way you think it should, it still wouldn't do
what you want to do. It wouldn't give you access to the colling sub's
return, it would just replace the nested sub with the CORE routine,
exit, and leave you right beck where you were, waiting for the outer
sub to exit.
And really, that's a good thing. Despite the potential onerousness
(onerosity?) of having to type "return" every place you want to, well,
return, you don't want subs to have access to other subs internals, at
least not as a matter of course. What happens when the inner sub
returns the outer sub before returning itself, especially if things
have been passed in by reference? A memory leak? A mess for the
garbage collector to apply expensive logic to sort out? Not to mention
that your lexical scoping goes right out the window.
Best,
-- jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org
values of β will give rise to dom!
