> @@ -64,6 +66,7 @@
> void restartContainer(@PathParam("id") String id);
>
> @Named("containers:deploy")
> + @Fallback(NullOnContainerResourceUnavailableAnd500.class)
I would remove this fallback, for several reasons: First, we shouldn't return
`null` lists; we should fallback to an empty one. And also in a POST or PUT
operation, a "unexisting resource" failure is ambiguous. What does a
`null`return value mean? Does it mean that the resource you are posting to does
not exist? Does it mean that the operation succeeded but returned no result?
The "return null" fallbacks are used in GET operations, to return null when a
404 response is returned. They map a not found error to a null return value,
because that makes sense in the scope of a read operation. But when you are
creating or modifying a resource, silently returning that is ambiguous.
The fallback should be removed from here, and let the method populate an
exception. Then, the error handler should do the same thing the fallback does
now, and throw a `ResoueceNotFoundException` or a generic
`HttpResonseException` depending on the cause of the failure.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/149/files#r26262980
