Introduce custom error types
Explain your use case
All the errors from SDK now returns in raw format. Moreover - they are bubbling up from the very bottom level to the client level.
Describe the problem you’re trying to solve
This errors might be everything - starting from the HTTP errors (can't connect to the server, wrong credentials, smth else) to JSON umarshaling problems.
Does the client really need such verbose level of errors and does he (she) really need to know that we've got some problem during JSON unmarshaling?
Do you have a proposed solution?
- Catch errors before returning to clients
- Introduce some types of errors (internal error, server error, auth error ...)(
- Introduce some interfaces that would help to separate errors by behavior (fatal, retryable, limit exceed) - here is a good article about it https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
Did anyone ever pick this up? We're planning on using cloudinary-go but it not returning errors properly is an issue.
I'm checking internally right now and will keep you posted.
Just to follow up that we have an internal ticket to handle this. I will keep you posted on it's status.
@momoip Thank you. Do you have any ETA on when we can expect this?
@makupi This is not planned for this quarter. I will keep you posted.