> On 11 Νοε 2011, at 10:13 π.μ., Kin Mak wrote:
>> The following code used to work fine prior to iOS 5. The dateFromString
>> method seems to stop working on iOS 5 and always returns null.
2011/11/11 Νικόλας Τουμπέλης <nicktoumpe...@gmail.com>:
> I've tried the snippet in both Mac OS X and iOS and found that it still
> works. What are you doing prior to calling dateFromString: ?
Kin,
Does dateFromString also return NULL in the Simulator?
If it works for Nick but not for you, possibly there is a bug
elsewhere in your own code that is screwing up the date formatter.
The fact that it returns NULL suggests that a memory allocation
failed. You're not likely running out of memory, but a corrupt heap
could cause allocations to fail.
Try turning on all the malloc diagnostics in your debug build's scheme
editor. Enable Guard Malloc when running in the Simulator. (Guard
Malloc is not yet supported on devices.)
Try calling dateFromString as the very first line of code in main().
If it works there but not in your original code, you probably have a
bug that occurs in the time duration from the entry of main until you
reach your original code. If you think that could be the case, use a
binary search to narrow the problem down, by estimating where the
halfway point in time is, testing there, and so on.
In general, it is useful to everyone to make liberal use of the
assert() macro. I cannot emphasize this enough. I call assert() "The
Test That Keeps On Testing". Even if none of your assertions are
presently failing, if you leave them in your code and keep them
enabled in debug builds, it is quite likely that introducing a bug at
some point in the future will trip one of your existing assertions.
The easiest way to use assert() is to validate all of the parameters
to each of your methods and functions. Such asserts also serve to
document the API or your methods and functions far better than do
comments. While comments have no particular requirement that they be
updated to keep them in sync with code changes, changing your APIs
without also revising your assertions will cause them to trip.
Use assert() only to test for conditions that cannot possibly happen
except as a result of programmer errror. Do not use them to test for
runtime failures or user error. Use some other means of error
recovery for that.
Your program should behave in precisely the same way whether or not
assertions are enabled. Having them enabled will make your executable
file a little bigger and your App will run a little slower, but the
difference in speed will just about always be insignificant to the
user.
The following code is quite *WRONG*, because it uses assert() to check
for a failure that can happen as a result of limited system resources:
- (unsigned char*) foo
{
unsigned char *result;
result = malloc( kBufferSize );
assert( NULL != result ); // This is a bug!
[initBuf result];
return result;
}
However, the following is a correct use of assert. We handle the
memory allocation failure gracefully, then assert that the buffer
pointer is non-NULL upon entry to a method that requires pointers to
be valid:
- (unsigned char*) foo
{
unsigned char *result;
result = malloc( kBufferSize );
if ( NULL == result )
return result;
[initBuf result]; // We are now certain result is not NULL
return result;
}
- (void) initBuf: (unsigned char*) bufPtr
{
assert( NULL != bufPtr ); // Correct use of assert
...
return;
}
Hope That Helps,
Don Quixote
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
