I am trying to execute a perl script in that we have statement like this-
# Calculate password using PwdMangler
$PwdMangler = Win32::OLE->new('PWDMangler.Mangler');
unless($password = $PwdMangler->Mangle($user , $password_plain))
{
print $log_file "Error occured in PwdMangler\n";
exit (1);
} # End Unless
but this perl is giving an error like this-
Can't call method 'Mangle' on an undefined value.
So, i tried to print $user and $password_plain values and i am able to capture these values.
Any suggestion for this error.
From CPAN: The new() class method starts a new instance of an OLE Automation object. It returns a reference to this object or undef if the creation failed.
You should check if the PWDMangler.Mangler is a proper program id.
P.S.: Don't want to look dumb, but are you sure that PWDMangler should not be PWDManager?
Related
I have a monthly Script running to archive files from past month. I'm using Archive::Tar to generate the archive. How can I check if calls to the ->write method are successful?
Does the following work? I didn't manage to fail $tar->write() yet.
unless ($tar->write( $name . '.tar.xz', COMPRESS_XZ )) {
die("cant write tar"); # or any other doings instead
}
Yes, the code in your question will catch any error within ->write.
The documentation of Archive::Tar does not specify what the return value of write is (except when no argument is provided, which isn't the case here). However, looking at the code of the module, write returns undef in case of an error and a true value in case of success:
1 if it was writing to a file (this is the case for the code in your question)
the written string if it was writing in a string.
Note that if something goes wrong and Archive::Tar returns undef, then it will also print an error message (unless you set $Archive::Tar::WARN to 0 by doing $Archive::Tar::WARN = 0). If you want to do something specific depending on the error, you can access the error message using the ->error method.
Looking for help figuring out a stumping error.
I've created a perl Catalyst plugin that's intended to provide a drop-in replacement method for Catalyst 5.90115's redirect_and_detach ($c->redirect_and_detach). My replacement method does nothing but call Catalyst's redirect_and_detach:
package MyApp::Catalyst::Plugin::Logger;
...
sub my_redirect_and_detach {
my ($c, $uri, $status) = #_;
$c->redirect_and_detach($uri, $status);
}
I realize this adds no value, I'm just testing to make this simple case work first.
Then I replace this working call ...
$c->redirect_and_detach($someuri);
with this call to my new plugin method ...
$c->my_redirect_and_detach($someuri);
And I get the following (abbreviated/obfuscated) error:
Parameter #2 (undef) to Catalyst::Plugin::RedirectAndDetach::redirect_and_detach was an 'undef', which is not one of the allowed types: scalar
at /usr/local/share/perl/5.26.1/Catalyst/Plugin/RedirectAndDetach.pm line 18.
Catalyst::Plugin::RedirectAndDetach::redirect_and_detach(undef, "/myuri", undef) called at /var/app/lib/MyApp/Catalyst/Plugin/Logger.pm line 95
MyApp::Catalyst::Plugin::Logger::my_redirect_and_detach(MyApp=HASH(0x5628f93e4e60), "/myuri") called at ...
I understand the Catalyst method spec requires parameter #2 to be defined. But I don't understand why the stacktrace shows undef for the first argument (thought that would be $c's class/package). I verified $c is successfully passed as first argument, and works inside my_redirect_and_detatch() to pull request parameters.
Anyone see the issue?
Thanks in advance.
Turns out Catalyst's redirect_and_attach(), while $status defaults to undef if not supplied, does not like an actual undef $status parameter. Solution is to avoid passing $status if it's undef.
I wrote a procedure which imports data from an xml-file into a MariaDB using library DBI. The procedure works but I don't understand why the following code gives me the message:
use of uninitialized value $DBI::err in concatenation (.) or string at ...
Here the code (abbreviated):
my $insert_art = $dbh->prepare(
"INSERT INTO odbb_articles (creation_dt,ref_data,comp_no)".
"VALUES (?,?,?)"
);
....
my $comp_no = $xpc->findvalue('./sr:ARTCOMP/sr:COMPNO',$node1);
....
$insert_art->execute($creation_dt,$ref_data,$comp_no)
or die "Fehler bei der Ausfuehrung: ".
"$DBI::err -> $DBI::errstr (odbb_articles $DBI::state)\n";
If I insert the code
if ($comp_no eq "") { $comp_no = undef; }
just before $insert_art->execute the procedure works. This error happens when there is no entry in the xml-file for element COMPNO. I can avoid it if I define it as undef. I just wonder
why $comp_no cause this problem and
is there another solution than to control if $comp_no is "" and define it as undef?
The reason for the second question is to avoid the if statement if there are a lot of variables/columns which may have empty entries.
Thanks for help.
use of uninitialized value $DBI::err in concatenation (.) or string at ...
The error message you are seeing is Perl telling you that $DBI::err is undef. That is not because of the value of your $comp_no. It's just a result of what your program is doing.
So when you pass an empty string to the comp_no column, the database doesn't like that. It throws an error. DBI catches that error and passes it on. The $insert_art->execute returns a false value and the right-hand-side of the or gets called. That's your die.
Now in the string that you pass to die you put three variables:
$DBI::err
$DBI::errstr
$DBI::state
According to the DBI documentation, those are equivalent to the functions $h->err, $h->errstr and $h->state with $h being the last handle used. Let's look at the docs for those.
$h->err
Returns the native database engine error code from the last driver method called. The code is typically an integer but you should not assume that.
The DBI resets $h->err to undef before almost all DBI method calls, so the value only has a short lifespan. Also, for most drivers, the statement handles share the same error variable as the parent database handle, so calling a method on one handle may reset the error on the related handles. [...]
This does not explain when it can be undef.
$h->errstr
Returns the native database engine error message from the last DBI method called. This has the same lifespan issues as the "err" method described above.
The returned string may contain multiple messages separated by newline characters.
The errstr() method should not be used to test for errors, use err() for that, because drivers may return 'success with information' or warning messages via errstr() for methods that have not 'failed'.
Ok, so this is text. Don't use it to test for specific errors. You're not doing that. You just want to give debug output when the program fails.
$h->state
Returns a state code in the standard SQLSTATE five character format. Note that the specific success code 00000 is translated to any empty string (false). If the driver does not support SQLSTATE (and most don't), then state() will return S1000 (General Error) for all errors.
The driver is free to return any value via state, e.g., warning codes, even if it has not declared an error by returning a true value via the "err" method described above.
The state() method should not be used to test for errors, use err() for that, because drivers may return a 'success with information' or warning state code via state() for methods that have not 'failed'.
Again, this is not very clear about how useful it is.
My advice is to get rid of $DBI::err and $DBI::state. You don't need those to figure out what the problem is. Just output $DBI::errstr.
$insert_art->execute($creation_dt,$ref_data,$comp_no)
or die "Fehler bei der Ausfuehrung: " . $dbh->errstr;
Now your program will still fail, but at least you will have a meaningful error message that will explain what your database didn't like about the statement. That's better than being told how there is a bug in your error handling code.
Afterwards, the other answers will probably apply to fix the reason this is happening in the first case.
On another note, a word on die: If you provide a \n at the end of your arguments, it will not print your current script, line number and input handle line number. But those might be useful in your case. You can include them.
In a SQL database an empty string is very different to null.
If comp_no has a foreign key pointing to a record in another table, then the value "" is an accettable one only if there is a record with "" as primary key, very improbable.
Yu can fix this converting empty values to undef:
for ($creation_dt,$ref_data,$comp_no ){
defined $_ and $_ eq '' and $_ = undef;
}
$insert_art->execute($creation_dt,$ref_data,$comp_no);
or also
$insert_art->execute(map {defined($_) && length($_) ? $_ : undef} ($creation_dt,$ref_data,$comp_no));
This is a possible shortcut:
$comp_no ||= undef;
With the caveat that this will work in any case where $comp_no evaluates as false, meaning a value of 0 will actually cause the result to go undef also, which may or may not matter to you. If your field is numeric, I'd say it matters a lot.
This is an odd one. I have this method, that is the callback for the FormEvents::POST_SET_DATA event in an EventSubscriber of a form in Symfony2:
public function preSetData(FormEvent $event)
{
$data = $event->getData();
$form = $event->getForm();
$resource_provider = $data->getResourceProvider();
$type = $resource_provider->getType(); //PROBLEM HERE
\Doctrine\Common\Util\Debug::dump(is_object($resource_provider));
}
It has more code but the error is firing in the line with the comment PROBLEM HERE.
The issue is that the dump there prints bool(true), so it is an object, and have the data inside, but trying to call getType(), that exist, fails with this error:
Error: Call to a member function getType() on a non-object
To add more confusion, if I dump $resource_provider->getType() I get the expected content dumped, but the error remains.
Does someone knows or has a clue on what can be happening here?
EDIT
Can't believe it! I found the answer, but doesn't makes sense at all! I had to wrap the problematic code with a conditional like this:
if(is_a($resource_provider, 'My\Bundle\Path\Entity\ResourceProvider')){}
and it worked! If someone can tell me what is the sense of that, I will happily select his/her answer as correct.
The problem is that $resource_provider is probably null as error says $resource_provider is not an object.
When printing the value of $resource_provider and skipping the script, it shows the right object of class 'My\Bundle\Path\Entity\ResourceProvider' :
echo get_class($resource_provider); exit; // Display My\Bundle\Path\Entity\ResourceProvider and skip the script
When adding a condition to test is the object is of the expected class, the script doesn't crash anymore :
if(is_a($resource_provider, 'My\Bundle\Path\Entity\ResourceProvider')){}
In addition, when skipping script when it's not an object, $resource_provider is null and the script skipped :
if(is_a($resource_provider, 'My\Bundle\Path\Entity\ResourceProvider')){
} else {
var_dump($resource_provider); exit;
}
$resource_provider is an object and null in the same "execution" of the script.
So we can deduce that the EventSubcriber is loaded more than one time, perhaps before the form binding and after form binding for example and the first time with the expected object, and a second (or more) time with no value, as null, perhaps because the $resource_provider is not filled when submitting form or something else.
i am writing a small perl app using the eXist database, and i am wondering is:
how can i see that my call
my $eXist = XML::eXistDB::RPC->new( destination=>$eXist_db, repository=>$bank, user=>"admin", password=>"pass" ) ;
is successful or not ?
thanx
When object initialisation fails, it will be messaged through Log::Report, so hook into that.
This only happens if the programmer to neglected to set either rpc or destination parameter. The new constructor will always return an object instance.
According to the docs:
All methods return a LIST, where the
first scalar is a return code (RC).
When that code is 0, all went well.
Otherwise, the code represent the
transport error or the exception
(refusal) as reported by the server
logic. In either case, the second
scalar in the returned list contains
the error message. For instance,
Maybe this applies also for the constructor, try:
my ($rc,$eXist) = XML::eXistDB::RPC->new( destination=>$eXist_db, repository=>$bank, user=>"admin", password=>"pass" );
now, if $rc != 0 there was an error.