[
https://issues.apache.org/jira/browse/LIBCLOUD-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13666965#comment-13666965
]
Jayyy V commented on LIBCLOUD-331:
----------------------------------
I see ProviderError can fit in between LibcloudError and its provider specific
sub types.
Proposed Hierarchy
-------------------
LibcloudError(Exception)
ProviderError(LibcloudError)
InvalidCredsError(ProviderError)
Compatibility
-------------
Existing clients should be handling the types Exception, LibcloudError and
other sub types of LibcloudError.
The changes should seamlessly fit in as the ProviderError is still a
LibcloudError and gets caught by existing clients as such except when errors
are raised by libcloud.common.base.Response constructor
if not self.success():
raise Exception(self.parse_error())
Changing this to raise ProviderError(self.parse_error()) might break a
following client code:
try:
driver.operation()
except LibcloudError:
#handle
except Exception:
#handle
Other Errors
-------------
I think errors like ContainerDoesNotExistError are of provider's (HTTP 404)
like InvalidCredsError (HTTP 401).
I noticed few other cases in drivers where LibcloudError is used to raise
provider specific validation errors.
* gogrid
raise LibcloudError('No public unassigned IPs left'
* joyent
msg = 'Invalid location: "%s". Valid locations: %s'
raise LibcloudError(msg % (kwargs['location'],
', '.join(LOCATIONS)), driver=self)
Assume if the request is fired without this validation, provider might throw
the same error. I suggest any validation that a driver does on behalf of
provider should use ProviderError.
What do you think?
> proposal to add a new error type - ProviderError
> ------------------------------------------------
>
> Key: LIBCLOUD-331
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-331
> Project: Libcloud
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.12.3
> Reporter: Jayyy V
> Priority: Minor
>
> libcloud.common.base.Response constructor is handling failures of provider
> operations, this way
> if not self.success():
> raise Exception(self.parse_error())
> for eg., in ec2 driver the parse_error method is overridden to handle
> specific cases like invalid credentials, malformed responses but all other
> error cases produced by ec2 will be raised as Exception. Its too generic and
> we need a classification (ProviderError) to capture all the errors generated
> by a cloud provider.
> * libcloud.common.base.Response can use it
> if not self.success():
> raise ProviderError(self.parse_error())
> * specific errors of providers can be derived from it
> class InvalidCredsError(ProviderError):
> Also drivers that are having provider specific error types (eg.,
> SoftLayerException, LinodeException, HostVirtualException) can be extended
> from ProviderError. Currently its extending LibcloudError and since
> LibcloudError is inclusive of all internal stuffs, having a separate type for
> errors occured at provider side would simplify error handling for libcloud
> clients.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
