Throw S3FileStorageException when something goes wrong and response is not as expected. #305
Conversation
…s not as expected for GetFileStreamAsync, GetFileInfoAsync, and ExistsAsync.
|
|
|
There is a failure on Queue tests, but this PR touches only FileStorage, maybe future merges can solve this. |
| } catch (AmazonS3Exception ex) { | ||
| if (ex.StatusCode == System.Net.HttpStatusCode.NotFound) | ||
| return null; | ||
| throw new S3FileStorageException("Error accessing S3 storage: " + ex.Message, ex); | ||
| } |
There was a problem hiding this comment.
Would be nice to use exception filters here
Co-authored-by: Blake Niemyjski <bniemyjski@gmail.com>
|
In this specific case, trace/debug logging I think isn't needed, because in case of not-managed error, an exception is thrown to the caller. |
| using System.Collections.Generic; | ||
| using System.Text; | ||
|
|
||
| namespace Foundatio.AWS.Storage { |
There was a problem hiding this comment.
We definitely don't want to have exceptions that are unique to each implementation where a user would need to check for different kinds of exceptions depending on which implementation they are using.
| return null; | ||
|
|
||
| if (res.HttpStatusCode != System.Net.HttpStatusCode.OK) |
There was a problem hiding this comment.
We are probably going to want to think about some sort of retry mechanism for things that can be retried. I guess it doesn't need to be part of this change though.
This PR changes GetFileStreamAsync, GetFileInfoAsync, and ExistsAsync.
The changes test for precise response status code, in order to avoid silent catching of particular S3 errors.
All tests passes, but not new tests were added because of the difficult to simulate errors. A classic error simulation is network error, but this already throws other exceptions.
Related to FoundatioFx/Foundatio#281