+1 even better
On 14/11/2013 10:11, Ignasi wrote:
Thinking a bit more about this, as HttpResponseException is already
propagated, would it make sense that provider specific exceptions
extend it instead of adding a new exception to the jclouds exception
model? In the end, these kind of provider exceptions should be
generated by the corresponding error handler, and there is all the
context (HttpCommand & HttpResponse) required to build the
HttpResponseException.
The more I think about it, the more I like the idea of extending
HttpResponseException.
Thoughts?
On 14 November 2013 11:02, Alex Heneveld
<alex.henev...@cloudsoftcorp.com> wrote:
+1
good clean solution in this case and I bet it will be useful elsewhere
hopefully this ProviderException hierarchy in turn extends RuntimeException
--A
On 14/11/2013 09:09, Ignasi wrote:
Hi!
Recently, to deal with a corner case in Softlayer, a patch [1] was
submitted to create a specific exception to treat that concrete case.
The idea was that clients could catch that provider specific exception
and handle it accordingly.
However, the created exception extended RuntimeException, and due to
how the exceptions are propagated in jclouds, the
HttpResponseException was actually being propagated instead of the
custom one. See [2] for the details. The problem is that jclouds only
propagates a small set of exceptions (auth exception, illegal state,
resource not found, and a few more), which is not very flexible.
I think it would be a good idea (as explained in the last comment), to
create an exception (ProviderException or whatever) that providers
could extend to propagate specific and controlled exceptions to let
clients handle this kind of corner cases properly.
WDYT?
Ignasi
[1] https://github.com/jclouds/jclouds/pull/200
[2] https://github.com/jclouds/jclouds/pull/204/files#r7647046
