Issue #162 new

Reraise boto/httplib errors as IOErrors

melinath avatarmelinath created an issue

The s3boto backend currently lets exceptions from the connection to s3 propagate. It seems like the correct behavior would be to catch these and reraise them as IOErrors, to more closely emulate the behavior of (say) the filesystem backend.

Affected exceptions would include:

  • httplib.IncompleteRead
  • boto.exception.BotoServerError
  • boto.exception.S3ResponseError
  • ssl.SSLError

There are probably other exceptions which it might also make sense to catch and reraise as IOError; these are just the ones I've run into.

Comments (3)

  1. Ian Lewis

    The FileSystemStorage throws IOErrors just because that's what get's thrown by the standard library routines. The storage api doesn't really specify that you should throw a particular kind of error so I'm would be wary of catching and wrapping errors because the original error becomes much more obtuse.

  2. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.