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(...);

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to