Issue #26 resolved

Improve handling of Google Storage errors

David Kocher
created an issue

The error format at Amazon is {{{

!xml

<?xml version="1.0" encoding="UTF-8"?> <Error> <Code>NoSuchKey</Code> <Message>The resource you requested does not exist</Message> <Resource>/mybucket/myfoto.jpg</Resource> <RequestId>4442587FB7D0A2F9</RequestId> </Error> }}}

Google Storage has an additional //Details// element

{{{

!xml

<Error> <Code>NoSuchKey</Code> <Message>The specified key does not exist.</Message> <Details>No such object: bucket10/file.html</Details> </Error> }}}

Documentation at http://code.google.com/apis/storage/docs/reference-status.html#errorformat

Comments (5)

  1. James Murty repo owner

    Interesting. I assume by better handling you mean that service exceptions thrown by JetS3t should include the Details information in their printed summary and make it available via a getter method?

    My first instinct is to create a subclass of S3ServiceException that recognises the Details element instead of RequestId. It would be messy but would work with the existing service methods, all of which throw the concrete S3ServiceException (I'm now regretting all these S3-specific names)

    A better approach would be to restructure the class hierarchy to make the service, exceptions, and classes in general less S3-specific. That's much more work but saner.

  2. David Kocher reporter

    For me it would just be fine if you concatenate the message and the details if available. No worry about the S3 naming conventions; it still is the S3 protocol implemented by Google Storage.

  3. Anonymous

    If different S3 implementations start putting in different fields, shouldn't you use either raw XML or a java.util.Map<String, String>?

  4. Log in to comment