Hi Nick,
The code works fine in iOS 4.3 or earlier, but not anymore on iOS 5.0. I didn't
try it on Mac OSX tough
But if you try the code on different versions of iOS, the result may not be the
same.
Don Quixote,
Thanks for your tips of using assert. I am now wondering if there is anything
to do with memory instead.
In fact after reading your email, I have written a simple UnitTestCase using a
similar approach, namely using STAssertNotNil :
- (void)testFormatter {
NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
[formatter setDateFormat:@"yyyy-MM-dd HH:mm:ss.SSS zzz"];
NSString *currentString = @"2011-11-11 11:00:00.000 CET";
NSDate *date = [formatter dateFromString:currentString];
[formatter release];
STAssertNotNil(date, @"Formatter failed to convert", nil);
}
This simple unit test works fine on iOS 4 with simulator iOS 4.3, but fails on
iOS 5 with simulator iOS 5.0.
I'll now turn on Guard Malloc, and see if I can find out something more.
Thanks for the advice/help from you two.
Thanks again,
Kin
On Nov 11, 2011, at 7:42 PM, Don Quixote de la Mancha wrote:
>> 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/kinmak%40me.com
>
> This email sent to kin...@me.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
