Comments (2)
Most likely you mean this quote from the Error Handling Programming Guide:
Important: Success or failure is indicated by the return value of the method. Although Cocoa methods that indirectly return error objects in the Cocoa error domain are guaranteed to return such objects if the method indicates failure by directly returning nil or NO, you should always check that the return value is nil or NO before attempting to do anything with the NSError object.
To date, none of the methods with indirect errors used by RMStore return garbage, and it would require a very oblivious developer at Apple to change this. However, it would be safer to use the return value to check for success.
Want to submit a pull request fixing the ones you find?
That said, I find the documentation of the return value of sendSynchronousRequest:returningResponse:error:
ambiguous.
The downloaded data for the URL request. Returns nil if a connection could not be created or if the download fails.
This is not the same than "Returns nil if any error is encountered." How can we be sure that the method will not return partial data under any circumstance?
from rmstore.
Hi Hermes,
Yes that excerpt is exactly the one that I remember having read. Other occurrences of this pattern on the RMStore classes are found around calls to JSONObjectWithData:options:error:, in this case the docs are clear enough:
error. If an error occurs, upon return contains an NSError object that describes the problem,
returns a Foundation object from the JSON data in data, or nil if an error occurs.
So for this case it is clear that we should check the returned value instead of the error object.
Now, the documentation on the sendSynchronousRequest:returningResponse:error: is not that explicit but it still states what it does, read through the end.
According to my previous experience, methods returning an NSError by reference do not set the passed in value unless there is an actual error. This is why I am surprised -and confused- about why the RMStore does not crash. I have not tested it, only looked at the code, but I clearly see that the verifyRequestData method may return failure when there is no error, and thus the app would crash when attempting to dereference the underlying error error object. This is at least what would have happened before ARC. My only guess is that maybe ARC initializes everything to nil even it it is declared on the local scope, so in fact NSError *error; is equivalent to NSError *error=nil; This is the only reason for why it would not crash. But I don't think this is the case.
In any case, I think that it would be safer to test for nil against the returned NSData. On all my previous uses of the method sendSynchronousRequest:returningResponse:error I found that:
1- If data is nil it is always because an error and the error is set.
2 -The method can return some data on error, but on this case the error is not set. This is consistent with what we should expect. The error in this case can be detected by checking the statusCode property of the returningResponse.
So after all what the docs state is exactly what happen:
The downloaded data for the URL request. Returns nil if a connection could not be created or if the download fails.
Yes, exactly. And the error is set in such case. But a connection could be made with no error and still be a failure, this is then checked through the statusCode on the returned NSHTTPURLResponse
Joan
from rmstore.
Related Issues (20)
- How an appid can purchase the same automatic subscription product for multiple user IDs
- iOS 11 new storekit feature : buy in-app directly from apple store HOT 6
- RMAppReceipt RMASN1ReadInteger undefined behavior
- Update defaultStore to return instancetype?
- Create a new official fork to keep RMStore up to date HOT 3
- Crashes in `RMKeychainGetValue` HOT 1
- Subscription expired notification for auto-renewable subscription HOT 1
- Problems conflicting with BoringSSL HOT 1
- Will disconnect from keychain mean purchases can't be restored? HOT 1
- Getting SSServerErrorDoamin code=2059 HOT 1
- iOS 12 beta “can not connect itune store” HOT 1
- TestFlight vs Sandbox for RMAppReceipt
- Project Catalyst issue
- Checking for an active auto-renewable subscription returns incorrect results HOT 2
- Subscriptions HOT 3
- 用户第一次绑卡操作时候漏单处理 HOT 8
- 'RMStoreContentDownloader' defined here has different definitions in different modules; first difference is this method HOT 2
- Receipt is nil
- Does this support Xcode 13.4.1?
- Couldn’t communicate with a helper application
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rmstore.