The Config::Tiny parent class for Monitoring::Plugin::Config does not necessarily raise an exception in $@/$EVAL_ERROR on a failed call to its ->read() method. Indeed, it does not in most cases, at least in the most recent Config::Tiny.
If a file does not exist or for whatever other reason cannot actually be read--such as permissions problems--Monitoring::Plugin ends up reporting a "Missing config section" to the caller, which is misleading.
This information is available from the ->errstr() method of the base class, however, and an inspection of the code for the ->read() method in the parent class suggests the correct approach is to look for a return of undef from the ->read() method, and use the return value of ->errstr() as the reported error for ->_die(). This commit adds such a check.
To reproduce, given the following plugin mptest:
use strict;
use warnings;
use Monitoring::Plugin qw(%ERRORS);
my $mp = Monitoring::Plugin->new(
usage => '',
);
$mp->getopts;
$mp->plugin_exit($ERRORS{OK}, 'Done!');
Running it without options of course works, like so:
$ perl mptest
MPTEST OK - Done!
However, prior to this patch, if we specify --extra-opts with a nonexistent filename, we get a misleading error:
The
Config::Tiny
parent class forMonitoring::Plugin::Config
does not necessarily raise an exception in$@
/$EVAL_ERROR
on a failed call to its->read()
method. Indeed, it does not in most cases, at least in the most recentConfig::Tiny
.If a file does not exist or for whatever other reason cannot actually be read--such as permissions problems--
Monitoring::Plugin
ends up reporting a "Missing config section" to the caller, which is misleading.This information is available from the
->errstr()
method of the base class, however, and an inspection of the code for the->read()
method in the parent class suggests the correct approach is to look for a return ofundef
from the->read()
method, and use the return value of->errstr()
as the reported error for->_die()
. This commit adds such a check.To reproduce, given the following plugin
mptest
:Running it without options of course works, like so:
However, prior to this patch, if we specify
--extra-opts
with a nonexistent filename, we get a misleading error:With this patch included, the error is more accurate and helpful: