Optionally raise detailed exceptions vs. returning False

[haikuginger]

Currently, python-saml has a number of cases where methods simply return False on failure. This prevents error details from bubbling up and being saved for retrieval.

This change decorates those methods with a decorator that, by default, returns False when an exception is raised. However, internally to python-saml, those exceptions are raised and saved for retrieval with get_last_error_reason.

As a result, more detail is available for diagnostics, but the overall API is preserved, because, by default, those exceptions are suppressed when the methods in question are called directly.

Unit tests have been added to ensure that the appropriate exception is raised in all places where False is currently returned when the raise_exceptions=True keyword argument is passed, and existing tests checking that these methods return False when that keyword isn't passed remain as written.

[haikuginger]

@pitbulk, we've been using this code in production for a bit without any issues. Any chance we could get it reviewed to see if it fits in here? It doesn't alter the existing API at all; it just opens up some additional options.

[pitbulk]

@lorenzogil what do you think about this?

[lorenzogil]

I personally think exceptions for errors is an improvement over returning booleans and having to check the result of each call I make to a library. With exceptions I can centralize my error checking into fewer parts of my application.

Having said that, this patch is an opt-in feature that the library gives you the choice to take. So I think it doesn't hurt. With testing support it will be not too hard to maintain in the future.

[pitbulk]

thanks @lorenzogil

[pitbulk]

Close it, will merge all in #175

[pitbulk]

@haikuginger can you review #175?