Suppression of error messages if a regex does not match

Discussion in 'Perl Misc' started by David Joseph Bonnici, Jun 1, 2005.

  1. 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
     
    David Joseph Bonnici, Jun 1, 2005
    #1
    1. Advertising

  2. David Joseph Bonnici wrote:
    > 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";
    }

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Jun 1, 2005
    #2
    1. Advertising

  3. David Joseph Bonnici wrote:

    > 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
     
    Mark Clements, Jun 1, 2005
    #3
  4. On Wed, 1 Jun 2005, David Joseph Bonnici wrote:

    > "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.
     
    Alan J. Flavell, Jun 1, 2005
    #4
  5. David Joseph Bonnici

    brian d foy Guest

    In article <429dd802$0$25045$>, Mark Clements
    <> wrote:

    > David Joseph Bonnici wrote:
    >
    > > 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.


    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;

    --
    brian d foy,
    Subscribe to The Perl Review: http://www.theperlreview.com
     
    brian d foy, Jun 2, 2005
    #5
  6. David Joseph Bonnici

    brian d foy Guest

    In article <>,
    Alan J. Flavell <> wrote:



    > 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. :)

    --
    brian d foy,
    Subscribe to The Perl Review: http://www.theperlreview.com
     
    brian d foy, Jun 2, 2005
    #6
  7. On Wed, 1 Jun 2005, brian d foy wrote:

    > Alan J. Flavell <> wrote:
    >
    > > 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.


    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.
     
    Alan J. Flavell, Jun 2, 2005
    #7
  8. Alan J. Flavell wrote:

    > On Wed, 1 Jun 2005, brian d foy wrote:
    >
    >
    >>Alan J. Flavell <> wrote:
    >>
    >>
    >>>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.

    >>
    >>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.


    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.

    >>I generally advise people to turn off warnings in production scripts.

    >
    > 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.
     
    Brian McCauley, Jun 2, 2005
    #8
  9. David Joseph Bonnici

    brian d foy Guest

    In article <d7n7u3$gg7$>, Brian McCauley
    <> wrote:

    > 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).

    --
    brian d foy,
    Subscribe to The Perl Review: http://www.theperlreview.com
     
    brian d foy, Jun 2, 2005
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. hiwa
    Replies:
    0
    Views:
    653
  2. Steven Buroff
    Replies:
    5
    Views:
    5,540
    Alan Moore
    Sep 28, 2004
  3. Replies:
    0
    Views:
    989
  4. coder

    Suppression of URL details

    coder, Dec 11, 2007, in forum: HTML
    Replies:
    27
    Views:
    962
    dorayme
    Dec 20, 2007
  5. , India

    question on assignment suppression in scanf

    , India, Oct 18, 2008, in forum: C Programming
    Replies:
    2
    Views:
    380
    Ben Bacarisse
    Oct 18, 2008
Loading...

Share This Page