I agree with @blackskad.

In the PHP library, I'm also catching all exceptions internally and log the results only.

In retrospective though, doing that was not a good idea, because all consumer code now always needs to check whether the return value contains the regular and expected data, or whether an error happened, and if an error happened, the consuming code needs to enter a different code path (e.g., triggering the fallback mode of either accepting or blocking all submissions).

I'd recommend to catch exceptions (and log) internally, but re-throw a custom/aggregated set of exceptions for the consuming code; e.g.:

* mollom.client.exception.NoResponseException (downtime, timeout)
* mollom.client.exception.UnexpectedResponseException (weirdness)
* mollom.client.exception.BadRequestException (faulty request parameters/endpoint/whatever)
* mollom.client.exception.RequestException (general networking/communication problem; e.g., outbound firewall)

In other words, do not expose the entire possible web service errors to the consumer, but instead, simplify all possible edge-cases into custom wrappers, so as to allow consuming code to focus on how to react.

Ideally make all of them extend a generic mollom.client.exception.ClientException, so that consuming code that doesn't care at all for the specific error can also catch them all at once.