Gentlemen, thank you for those succinct responses. I'll go through my code base
and make the necessary changes.
Best wishes,
Martin
On 24, Jun, 2012, at 07:55 AM, Conrad Shultz wrote:
As Roland indicated, yes, this is a general statement.
It would be advisable to read the Error Handling
On Jun 23, 2012, at 10:46 PM, Roland King wrote:
Yes that is a general statement. You should check the return value of the
method and only if it indicates there's an error, check the error object.
There is no guarantee that the error object was not set at some point during
the method
No.
On 24 Jun, 2012, at 11:14 PM, Dennis li...@dbandel.com wrote:
On Jun 23, 2012, at 10:46 PM, Roland King wrote:
Yes that is a general statement. You should check the return value of the
method and only if it indicates there's an error, check the error object.
There is no guarantee
On 24, Jun, 2012, at 05:14 PM, Dennis wrote:
On Jun 23, 2012, at 10:46 PM, Roland King wrote:
Yes that is a general statement. You should check the return value of the
method and only if it indicates there's an error, check the error object.
There is no guarantee that the error object
On Jun 24, 2012, at 8:14 AM, Dennis wrote:
What if you explicitly set your NSError variable's value to nil immediately
before using it? Wouldn't it be safe to trust in that case?
To expand on Roland's pithy No:
* You call method A with an NSError** that points to a nil pointer.
* A calls B,
Dear list,
I have an interesting bug report from a user of an app of mine. The app manages
files and allows the user to edit them. When they save the project each file is
saved to disk (if necessary). They are experiencing what appears to be a false
positive
, Martin Hewitson wrote:
Dear list,
I have an interesting bug report from a user of an app of mine. The app
manages files and allows the user to edit them. When they save the project
each file is saved to disk (if necessary). They are experiencing what appears
to be a false positive
files and allows the user to edit them. When they save the project
each file is saved to disk (if necessary). They are experiencing what appears
to be a false positive of writeToURL:atomically:encoding:error:. The file
actually does save, but the error comes back non-nil and when presented
from a user of an app of mine. The app
manages files and allows the user to edit them. When they save the project
each file is saved to disk (if necessary). They are experiencing what
appears to be a false positive of writeToURL:atomically:encoding:error:. The
file actually does save
On Jun 24, 2012, at 1:35 PM, Martin Hewitson wrote:
Just a quick follow up on this.
It's been stated that it's unsafe to check the error returned from
-writeToURL:atomically:encoding:error: and rather one should check the return
value. Is this a general statement for other methods which
As Roland indicated, yes, this is a general statement.
It would be advisable to read the Error Handling Programming Guide, which
includes, among other things:
Important Success or failure is indicated by the return value of the method.
Although Cocoa methods that indirectly return error
11 matches
Mail list logo
