In Flysystem, if you do something like a exists() check, and your permissions are not configured correctly on AWS - what happens is that Flysystem gobbles up the exception provided by guzzle, providing an error message like:
Unable to check existence for: filename.png
This is not particularly helpful. The issue in my circumstance was that AWS was returning a 403 forbidden response. After doing some digging I realised that I could actually pull in the previous exception and see its message, so debugging was a breeze after that.
I think it might be better if Flysystem conveyed the message provided by the original exception. This would make debugging a lot easier. I'm not sure this is a standard across the library, but perhaps worth entertaining?
Scenario / Use-case
File operations against AWS.
Summary
Improve debugging capabilities through clearer error message reporting.
Feature Request
In Flysystem, if you do something like a exists() check, and your permissions are not configured correctly on AWS - what happens is that Flysystem gobbles up the exception provided by guzzle, providing an error message like:
Unable to check existence for: filename.png
This is not particularly helpful. The issue in my circumstance was that AWS was returning a 403 forbidden response. After doing some digging I realised that I could actually pull in the previous exception and see its message, so debugging was a breeze after that.
I think it might be better if Flysystem conveyed the message provided by the original exception. This would make debugging a lot easier. I'm not sure this is a standard across the library, but perhaps worth entertaining?
Scenario / Use-case
File operations against AWS.
Summary
Improve debugging capabilities through clearer error message reporting.