Trapping warnings

R

Raj

Hi,

I am using some code to talk to a third party server via an HTTPS GET.

The problem I have is that when the server is unavailable, the object method
thrown an error of the form:

"(Use of uninitialized value in split at
/opt/perl5/lib/site_perl/5.6.1/sun4-solaris-64int/eo.pm line 151.)"

I need to be able to suppress these warnings, but trap them so that I can
report them back via my code gracefully.

I know I can trap die using eval() but what can I do to deal with the above
warning?

Thanks in advance!

Regards,
Raj
 
A

A. Sinan Unur

Hi,

I am using some code to talk to a third party server via an HTTPS GET.

The problem I have is that when the server is unavailable, the object
method thrown an error of the form:

"(Use of uninitialized value in split at
/opt/perl5/lib/site_perl/5.6.1/sun4-solaris-64int/eo.pm line 151.)"

I need to be able to suppress these warnings, but trap them so that I
can report them back via my code gracefully.

I know I can trap die using eval() but what can I do to deal with the
above warning?

Well, how about not using split if there is nothing to split?
 
G

GM

A. Sinan Unur said:
Well, how about not using split if there is nothing to split?

Ditto!

You should be looking at what you get back from the server before trying
to do anything with it.
 
R

Raj

GM said:
Ditto!

You should be looking at what you get back from the server before trying
to do anything with it.

But it is someone else's PM that I am using:

my $e = GL::eo::new (
host=>"$host", key=>"$key",
) || die("500");

my $path = $cfg->{GL}->{Path};

my ($p,$r,$h) = $e->do_request('GET', $path, undef); # this is the method
in which the split occurs

I cannot change the code for the do_request() method. Can I stop it from
throwing this error?

Regards (and thanks)

Raj
 
T

Thomas Kratz

Raj said:
But it is someone else's PM that I am using:

my $e = GL::eo::new (
host=>"$host", key=>"$key",
) || die("500");

my $path = $cfg->{GL}->{Path};

my ($p,$r,$h) = $e->do_request('GET', $path, undef); # this is the method
in which the split occurs

I cannot change the code for the do_request() method. Can I stop it from
throwing this error?

Do you use

#!perl -w

or

use warnings;

in your script?

IIRC the former will turn on warnings for all used modules too, whereas
the latter will only do so in the lexical scope it is used in.

If it happens with 'use warnings', then either

my ($p,$r,$h);
{
no warnings qw/uninitialized/;
($p,$r,$h) = $e->do_request('GET', $path, undef);
}

or trapping the __WARN__ signal with

local SIG{__WARN__} = sub {
...
do something with the warning message in $_[0]
...
}
my($p,$r,$h) = $e->do_request('GET', $path, undef);

will perhaps do what you want.

see also 'perldoc -f warn' and the section on %SIG in 'perldoc perlvar'

Thomas
 
B

Brian McCauley

Raj said:
I am using some code to talk to a third party server via an HTTPS GET.

The problem I have is that when the server is unavailable, the object method
thrown an error of the form:

"(Use of uninitialized value in split at
/opt/perl5/lib/site_perl/5.6.1/sun4-solaris-64int/eo.pm line 151.)"

I need to be able to suppress these warnings, but trap them so that I can
report them back via my code gracefully.

As others have pointed out, it would seem more logical to cope
gracefully with the situation that lead to the warnings in the first
place instead.
I know I can trap die using eval() but what can I do to deal with the above
warning?

1) You can promote warnings to errors and then trap them as errors.
(See perldoc perllexwarn).

2) You can redirect STDERR to a file (or string). This is fiddly and
IIRC a tied STDERR didn't capture warnings until very recently.

3) You can define a warning handler by assigning $SIG{__WARN__}.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
 
A

Anno Siegel

Brian McCauley said:
As others have pointed out, it would seem more logical to cope
gracefully with the situation that lead to the warnings in the first
place instead.


1) You can promote warnings to errors and then trap them as errors.
(See perldoc perllexwarn).

You can do that, but it must happen in the lexical scope of the
code that issues the warning. Since the function that issues the
warning is from a module not under OP's control, that won't help here.
2) You can redirect STDERR to a file (or string). This is fiddly and
IIRC a tied STDERR didn't capture warnings until very recently.

Up until 5.8.0 it caught some and didn't catch others in rather
unpredictable ways. In 5.8.1 and better it catches them all. That
is indeed very recently.
3) You can define a warning handler by assigning $SIG{__WARN__}.

I'm afraid that is the way to go. Something like

{
local $SIG{ __WARN__} = sub {
return if $_[ 0] =~ /uninitialized/;
warn @_;
};
# call the warning method
}

ought to do it.

Anno
 
B

Ben Morrow

Quoth Thomas Kratz said:
If it happens with 'use warnings', then either

my ($p,$r,$h);
{
no warnings qw/uninitialized/;
($p,$r,$h) = $e->do_request('GET', $path, undef);
}

or trapping the __WARN__ signal with

my ($p, $r, $h);
{
local SIG{__WARN__} = sub {
...
do something with the warning message in $_[0]
...
}
my($p,$r,$h) = $e->do_request('GET', $path, undef);
}


will perhaps do what you want.

Or, if it is old code that predates 'warnings',

my ($p, $r, $h);
{
local $^W;
($p, $r, $h) = ...;
}

Ben
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,051
Latest member
CarleyMcCr

Latest Threads

Top