On Thu, May 23, 2013 at 10:05:03PM +0200, Matthieu Moy wrote:
> My use-case is an invalid SSL certificate. Pulling from the wiki with a
> recent version of libwww-perl fails, and git-remote-mediawiki gave no
> clue about the reason. Give the mediawiki API detailed error message, and
> since it is not so informative, hint the user about an invalid SSL
> certificate on https:// urls.
This is definitely an improvement, but it seems like it just the tip of
the iceberg.
The call in get_mw_tracked_categories already uses die() with the MW
error code and detailed string. Good. The call you fix here prints a
guess to stderr and exits 1, and your patch improves that. But the call
in get_mw_first_pages does the same broken thing, and is not fixed.
Ditto for get_all_mediafiles. Other calls do not even seem to error
check the result at all, and assume the result is not undef (which I
suspect would produce a perl runtime error).
I wonder if we can do something like:
our $mw_operation;
$mediawiki->{config}->{on_error} = sub {
my $err = "fatal: ";
if (defined $mw_operation) {
$err .= "unable to $mw_operation: ";
}
err .= $mediawiki->{error}->{details};
die "$err\n";
};
and then callers do not have to worry about error-checking at all. If
they want a nicer human-readable indication of where the error occured,
they can do:
local $mw_operation = "get the list of remote wiki pages";
my $mw_pages = $mediawiki->list(...);
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html