Re: Should Test2 maintain $! and $@?
I agree, Kent. Shouldn't it be simple to wrap ok() and is() accordingly,
to simply save-and-restore $! and $@, without going deep into anything?
There's already a working example of how to do that right here.
sub ok {
my($err, $exception) = ($!, $@);
# ...
($!, $@) = ($err, $exception);
return $ret;
}
And if ok() accepts a code reference to execute, fine ... same principle,
for whenever you execute the code. It doesn't seem like it's a lot of
work, though I imagine I am probably missing something. That said, I
generally do something like you have, except I don't put it in a do(), I
just execute it external to the test function:
local($@, $!);
my $ret = do_something_scary();
($error, $exception) = ($!, $@);
ok($ret);
is($err, 0);
is($exception, undef);
It's not as nice, but it's safe. And if I call it multiple times, I
usually put it in my own wrapper:
sub my_test {
local($@, $!);
my($ref) = @_;
my $ret = $ref->();
($error, $exception) = ($!, $@);
ok($ret);
is($err, 0);
is($exception, undef);
}
or whatever. Again ... it's not ideal, but if I am calling it multiple
times, and I want to check for no errors, even if $@ and $! are protected,
I'd still want to have a separate function ... and then the overhead isn't
a big deal. So, I guess my point is "whatever." :-)
On Mon, Jan 11, 2016 at 5:34 PM, Kent Fredric wrote:
> On 12 January 2016 at 13:53, Chad Granum wrote:
> > $! and $@ are altered by many many things, adding { local ... } around
> all
> > of them is a pain
>
> As much as I agree, and as much as this is a "thing in all perl, so we
> should expect this problem from every module"
>
> If I was to offer a counter example, consider the effort of a `*.t`
> file needing to preserve these things instead.
>
> > ok(do_something_scary());
> > is($!, 0, "expected $! val");
> > is($@, undef, '$@ not changed');
>
> vs
>
> > my ( $error, $exception );
> > ok(do {
> > local $@;
> > local $!;
> > my $ret = do_something_scary());
> > ( $error, $exception ) = ($!, $@);
> > $ret
> > });
> > is($error, 0, "expected $! val");
> > is($exception, undef, '$@ not changed);
>
> I'm not sure I'd consider the second of these an "improvement".
>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
Re: Trimming the CPAN - Automatic Purging
What Jarkko said. On Mar 25, 2010, at 08:00, Jarkko Hietaniemi wrote: I have one case where the v1 and v2 of a module are simply incompatible, but v1 still works, and unless the users have a compelling reason, they won't migrate. Pulling the rug from under them would be quite unsportsmanlike. Deletion should be opt-in, and there should be a way to pin some releases as unreapable. And warning emails (yes, some email addresses are blackholes) to the author well in advance: your module X version Y will be deleted as you requested in Z weeks because there are P newer releases ... -- There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen -- Chris Nandor pu...@pobox.com http://pudge.net/ Slashdot / Geeknet pu...@slashdot.org http://slashdot.org/
Re: Fasten your SPAMbelts
At 17:51 +0900 2000.08.14, Simon Cozens wrote: On Mon, Aug 14, 2000 at 09:51:36AM +0200, Johan Vromans wrote: Seeing announcements like this makes me feel uneasy. How 'bout you? Subject: ANNOUNCE Mail::Bulkmail 2.00 Uhm, hm. Hard to tell. To use this to spam, you must already *have* a humping great list of addresses, and if you smack them at Sendmail they'll get through eventually. There was a bit of an outcry the first time this was released, but I think the author has since made it clear that this is for kosher mailing lists and the like. We certainly *don't* want to encourage spamming, but Perl certainly gives people the tools they need to do it. If it was a module for extracting mail addresses from the web or usenet posts, which you can combine with a crawler from LWP, and then bolt in Mail::Bulkmail... Blegh. Really hard to tell. I really like the Mail::Bulkmail module. It works well, it's fast, it does what I need it to do. I've been considering using it in the Slash code. Bulk mailing is not a problem. Spam is a problem. Yes, this module can and will be used for Spam. C'est la vie, I guess. However, I keep most of my Spam (about 4200 pieces since May 1997) and none of it has "Mail::Bulkmail" in the headers. I suppose that's good. :) -- Chris Nandor | [EMAIL PROTECTED] | http://pudge.net/ Andover.Net| [EMAIL PROTECTED] | http://slashcode.com/
