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 <[email protected]> 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 > >
