Re: Catching expressions from a file

Two problems stand out to me:

First:

if(@Functions =~ /$expr/gi)

needs to be

if (grep { /$expr/i } @Functions)

This will test each member of @Functions with your regular expression. What you wrote will compare the length of @Functions to your expression.

Also, the g in /gi is not needed.

So, the whole line is better written as

next if (grep { /$expr/i } @Functions);

Then:

if($1 =~ ""){goto cont1;}

Two things: The value of $1 is not guaranteed after a failed reg ex match. Also, you have an intervening, unrelated, reg ex match. The following should work:

next unless ($exp);

Now, a simple thing:

open (file1, "<$filename") or goto cont2;

is better written as

open (file1, "<$filename") or return;

If the open fails, there's nothing to close.

I hope this helps.

Comment on Re: Catching expressions from a file Select or Download Code

Replies are listed 'Best First'.
Re^2: Catching expressions from a file by GrandFather (Saint) on Jul 26, 2014 at 02:33 UTC
`open my $fIn1, '<', $filename or die "Failed to open '$filename': $!\n +";` [download] is much, much better than the two parameter version of open. If the OP really does want to fail silently then replacing the die with a return as you suggest is fine. Much better though is to leave the die there and have the calling code be explicit about error handling by wrapping the call in an eval and explicitly ignore expected failure modes: `eval { Grab($filename); return 1; } or do { my $err = $@; return if $err =~ /File not found/; die $err; };` [download] which gives good information about unexpected error modes and makes it clear that missing files are expected and unimportant (such failures are ignored). If you ignore error handling the errors will still happen and manifest themselves in some fashion. But most likely the way they manifest will not be at all obviously related to the underlying error. Spending a little time adding error handling up front almost always pays for itself. Even without writing any code, thinking about failure modes will head off many bugs before they get the chance to bite. Perl is the programming world's equivalent of English	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Catching expressions from a file
by GrandFather (Saint) on Jul 26, 2014 at 02:33 UTC

open my $fIn1, '<', $filename or die "Failed to open '$filename': $!\n
+";
[download]

is much, much better than the two parameter version of open. If the OP really does want to fail silently then replacing the die with a return as you suggest is fine. Much better though is to leave the die there and have the calling code be explicit about error handling by wrapping the call in an eval and explicitly ignore expected failure modes:

eval {
    Grab($filename);
    return 1;
} or do {
    my $err = $@;

    return if $err =~ /File not found/;
    die $err;
};
[download]

which gives good information about unexpected error modes and makes it clear that missing files are expected and unimportant (such failures are ignored).

If you ignore error handling the errors will still happen and manifest themselves in some fashion. But most likely the way they manifest will not be at all obviously related to the underlying error. Spending a little time adding error handling up front almost always pays for itself. Even without writing any code, thinking about failure modes will head off many bugs before they get the chance to bite.

Perl is the programming world's equivalent of English

[reply]
[d/l]
[select]