Suppression of error messages if a regex does not match

  • Thread starter David Joseph Bonnici
  • Start date
D

David Joseph Bonnici

Whenever I have a capture group that does not produce a match I am getting loads of
"Use of unitialized valie in string ne at "
Is there a way how I can suppress these error messages.

Many Thanks and
Kind Regards
David Joseph Bonnici
 
G

Gunnar Hjalmarsson

David said:
Whenever I have a capture group that does not produce a match I am getting loads of
"Use of unitialized valie in string ne at "
Is there a way how I can suppress these error messages.

They are warnings, not errors.

if ( /([a-z]+)/ ) {
print $1 ne 'foo' ? "Okay\n" : "Not okay\n";
}
 
M

Mark Clements

David said:
Whenever I have a capture group that does not produce a match I am getting loads of
"Use of unitialized valie in string ne at "
Is there a way how I can suppress these error messages.

You should always be testing for a successful match before using the captured match variables.

eg

if($testString =~/\b(\d+)\b/){
my $num = $1;
}

However, you can also check for definedness first:

my $capture = $1;
if(defined $capture && $capture ne "teststring"){

}

And (you probably don't want to be doing this), you can turn off warnings for a block.
See

perldoc warnings

Mark
 
A

Alan J. Flavell

"Use of unitialized valie in string ne at "

*Do* please get into the habit of copy/pasting the exact text of what
you are seeing. Re-typing it (badly) is no way to get help, and soon
you are going to find problems here.

Perl has a list of the diagnostic (error and warning) messages which
it issues itself (of which this is one), and you can look them up for
an explanation. The documentation comes with every Perl installation,
and there are also copies on the web.

perldoc perldiag


Conversely, I find that feeding an exact error message to a search
engine (e.g google) can often solve my own problems much faster than
posting to a usenet group, but mistyping the message pretty-much
guarantees very poor results from the search.
Is there a way how I can suppress these error messages.

You need to understand what you are seeing here. Perl is alerting you
to a potential problem, by means of a warning (not literally "error")
message.

So what do you really want to do? Make good use of Perl's help (which
is what I would recommend), or hide the problem away and hope for the
best?

The truth is that your program logic is faulty: you are trying to use
a variable to which you have not assigned a value. Perl is helpfully
alerting you to this. My advice is don't even think about suppressing
this valuable information: use it, work out what it's telling you.
Consider yourself lucky, that the failed match didn't leave some
unrelated value from a previous operation, which you would have used
without any warning. Correct your program logic so that you don't try
to use a match value when it hasn't been set.


If and when you're in a situation where you *really* want a variable
set to an empty value rather than being undefined, do what the
documentation says:

Use of uninitialized value%s
An undefined value was used as if it were already defined.
It was interpreted as a "" or a 0, but maybe it was a mistake.

To suppress this warning assign a defined value to your variables.

Which is a good answer, in appropriate situations. But that's not
what's needed here (regex match variables).


Anyone who advises turning warnings off to hide the warning may be
technically accurate about what Perl does or can do - but
operationally it's a disaster. The whole point of Perl's warnings and
strict pragmas are to help one find errors on one's code. Only in the
most extreme cases should it be necessary to turn these off briefly.
Consider all other possibilities first. That's my advice.
 
B

brian d foy

You should always be testing for a successful match before using the captured
match variables.

A successful match can still produce undefined memory variables, and
this warning. In this example, the match succeeds, but only $1 and
$3 get a value because the $2 portion was optional. Using $2 produces
a warning.

#!/usr/bin/perl -w

if( "foo bar" =~ m/(foo)\s+(baz)?(bar)/ )
{
print "1: $1\n2: $2\n3: $3\n";
}

With more recent perls, we can turn off classes of warnings, if we
wanted, for any particular scope.

no warnings 'uninitialized';

I'm more likely to be old-school when I want to turn off warnings
because some clients still deal with older perls:

local $^W = 0;
 
B

brian d foy

Anyone who advises turning warnings off to hide the warning may be
technically accurate about what Perl does or can do - but
operationally it's a disaster.

Well, I don't think it's always an operational disaster. I think
warnings are something we can use to understand what the code is
doing. When we know what it is doing and accept that in some cases
we know better than perl, turning off warnings is not a disaster.

I generally advise people to turn off warnings in production scripts.
Turn on warnings in development and debugging, but don't fill your
disk with warning messages just because someone upgraded perl (and
the new perl has a different idea about warnings). I've had clients
run out of disk space from that (back in the days before Gb was
a common measurement) situation, and those were minor disasters.

perl doesn't always know best. :)
 
A

Alan J. Flavell

Well, I don't think it's always an operational disaster. I think
warnings are something we can use to understand what the code is
doing.
Accepted...

When we know what it is doing and accept that in some cases
we know better than perl, turning off warnings is not a disaster.

Accepted - but first we *do* need to "know what it is doing", and be
sure that we really *do* know better than perl. I was intending to
talk about this development phase, but omitted to make that clear,
sorry.
I generally advise people to turn off warnings in production scripts.

Fair enough, but only after the development is complete; and be ready
to turn them back on again before thinking of posting a problem here
and asking for help.
Turn on warnings in development and debugging,
Right.

but don't fill your disk with warning messages just because someone
upgraded perl (and the new perl has a different idea about
warnings). I've had clients run out of disk space from that (back in
the days before Gb was a common measurement) situation, and those
were minor disasters.

OK. On the other hand I've had one case (maybe others have had their
own examples) where an upgraded perl started issuing warnings which
revealed a program logic error in my code. The error had always been
there, but previously un-noticed, and was easy to fix.

In a context where we're talking about CGI scripts, I'd also do
development with warnings sent to the browser (CGI::Carp), but I'd
turn that off in production, since it can reveal internal details
about a script to a hostile attacker.
 
B

Brian McCauley

Alan said:
Accepted - but first we *do* need to "know what it is doing", and be
sure that we really *do* know better than perl.

In the case of the 'numeric' and 'uninitialized' there can be _many_
times when we do know better. I would not suggest turning them off
globally but I think one should have absoultely no quarms at all about
conciously using the fact that undef behaves as a null string or that a
null string behaves as a zero where this makes for concise readable code.
Fair enough, but only after the development is complete;

I don't favour turning off warnings any more than I'd favour turning off
strictures.
 
B

brian d foy

Brian McCauley said:
In the case of the 'numeric' and 'uninitialized' there can be _many_
times when we do know better. I would not suggest turning them off
globally [snip]

Indeed, and I think I should have emphasized that before. In those
cases I turn off warnings for that scope (or create a naked block
scope if possible so I can limit the effect).
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top