You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Objective-C API 2 - dealing with error codes
Hello, In transitioning my API 1 Obj-C code over to API 2, I'm slightly confused over how to deal with certain error codes in API 2 - or even how to locate them properly. # 1. Create Folder E...
I see, if you're looking for that case in particular, in API v2 lock contention is now a 429 with a structured too_many_write_operations error. In the SDK that should be a DBAUTHRateLimitError with a TooManyWriteOperations DBAUTHRateLimitReason.
That helps lots, thank you! I think I'm nearly there... One question on (4):
What about for errors that aren't covered in the framework. For instance, if you recall, I found that I was encountering random 503 "failed to grab file lock" errors, in which case I would use the "retry-after" header. In API 2, the status code for this is 429. In this instance, I assume I still use the DBError's status code to check for this? Or is the "failed to grab file locks" error always the same as a rate limit error? Are you saying I should never need to call the statusCode property?
Thanks again,
Keith
Greg-DB
Dropbox Staff
Dropbox StaffI don't believe there's any case where you necessarily need to check the status code directly. The translation is here if you're interested, but a 503 will yield a DBRequestErrorInternalServer and a 429 will yield a DBRequestErrorRateLimit, so you don't need to access the statusCode directly for either of those. Further, anything not specifically covered there will be a DBRequestErrorHttp.
Great, thank you! With regard to a 503, though, a DBRequestErrorInternalServer is just a generic "anything over 500" error, isn't it? So if I want to check specifically for a file lock error, is it safe still to check for the 503 error? (That is, will DBError report a status code of 503 in this case?)
All the best,
Keith- Greg-DB
I see, if you're looking for that case in particular, in API v2 lock contention is now a 429 with a structured too_many_write_operations error. In the SDK that should be a DBAUTHRateLimitError with a TooManyWriteOperations DBAUTHRateLimitReason.
Perfect, thank you!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
