whindsx / bitcoin-rpc-client Goto Github PK

Not so recent changes to IO::Socket::SSL (v2.017) will cause the following to fail:

$btc = Bitcoin::RPC::Client->new(
    host     => $RPCHOST,
    user     => $RPCUSER,
    password => $RPCPASSWORD,
    port     => 8334,
    ssl      => 1,
    verify_hostname => 0,
);

In this case Debian 9 stretch:
SSL_verify_mode must be a number and not a string at /usr/share/perl5/IO/Socket/SSL.pm line 2227

When running a method on a new Client, it is possible to get this message when running an RPC function when the bitcoin node is not running locally:

malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Can't connect to 127...") at /home/user/perl5/lib/perl5/JSON/RPC/Legacy/Client.pm line 180.

You can reproduce this by using the first few lines of the example perl code from this module.

use [Bitcoin::RPC::Client](https://metacpan.org/pod/Bitcoin::RPC::Client);
 
# Create Bitcoin::RPC::Client object
$btc = Bitcoin::RPC::Client->new(
   user     => "username",
   password => "p4ssword",
   host     => "127.0.0.1",
);
 
# Check the block height of bitcoin node
#     https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html
$chaininfo = $btc->getblockchaininfo;

The problem is that the node is down, of course, but it would be nice if this module could return some kind of error message that can be handled rather than this crash about malformed JSON.

I've run the test code from the man page against by bch server and also my btc server .. neither seems to know what to make of this call.

$fee = $cli->estimatesmartfee(6);

Perl version: v5.26.2 x86_64-linux

If the RPC call returns an error for sample:
error code: -5, error message: Invalid address (getaddressinfo)

The message will be printed but we can't catch the exception in the tests because of the use of exit(1) and the bellow message will be triggered:

A context appears to have been destroyed without first calling release().
Based on $@ it does not look like an exception was thrown (this is not always
a reliable test)

This is a problem because the global error variables ($!, $@, and $?) will
not be restored. In addition, some release callbacks will not work properly from
inside a DESTROY method.

Following the exit docs https://perldoc.perl.org/functions/exit.html:

Don't use exit to abort a subroutine if there's any chance that someone might want to trap whatever error happened. Use die instead, which can be trapped by an eval.