• Choose a category
• All
• Classic-Fiction

This code will not create an error. Instead, it will simply go up the inheritance tree until it finds NSObject’s init method. The problem is that firstNumber and secondNumber will not get initialized properly—both will be zero.

To protect Rex from his own ignorance, you will override init to call your initializer with a default date:

- (id)init

{

return [self initWithEntryDate:[NSDate date]];

}

Add this method to your LotteryEntry.m file.

Note that initWithEntryDate: still does all the work. Because a class can have multiple initializers, we call the one that does the work the designated initializer. If a class has several initializers, the designated initializer typically takes the most arguments. You should clearly document which of your initializers is the designated initializer. Note that the designated initializer for NSObject is init.

Conventions for Creating Initializers (rules that Cocoa programmers try to follow regarding initializers):

• You do not have to create any initializer in your class if the superclass’s initializers are sufficient.

• If you decide to create an initializer, you must override the superclass’s designated initializer.

• If you create multiple initializers, only one does the work—the designated initializer. All other initializers call the designated initializer.

• The designated initializer of your class will call its superclass’s designated initializer.

The day will come when you will create a class that must, must, must have some argument supplied. Override the superclass’s designated initializer to throw an exception:

- (id)init

{

@throw [NSException exceptionWithName:@"BNRBadInitCall"

reason:@"Initialize Lawsuit with initWithDefendant:"

userInfo:nil];

return nil;

}

The Debugger

The Free Software Foundation developed the compiler (gcc) and the debugger (gdb) that come with Apple’s developer tools. Apple has made significant improvements to both over the years. This section discusses the processes of setting breakpoints, invoking the debugger, and browsing the values of variables.

While browsing code, you may have noticed a gray margin to the left of your code. If you click in that margin, a breakpoint will be added at the corresponding line. Add a breakpoint in main.m at the following line (Figure 3.10):

[array addObject:newEntry];

Figure 3.10. Creating a Breakpoint

When you run the program, Xcode will start the program in the debugger if you have any breakpoints. To test this, run it now. The debugger will take a few seconds to get started, and then it will run your program until it hits the breakpoint.

When your application is running, the debugger bar will be shown below the editor area. The debugger bar contains a button to toggle visibility of the full debugger area, including the variables view and console, as well as buttons to control the execution of your program and information about the current thread and function.

Xcode’s default behavior is to show the full debugger area when a breakpoint is hit. If you do not see the debugger area at the bottom of the window, use the debugger area view toggle in the debugger bar (or toolbar), or the View->Show Debugger Area menu item.

You should also see the Debug navigator on the left, which shows the threads in our application and frames on the stack for each thread. Because the breakpoint is in main(), the stack is not very deep. In the variables view on the left in the debugger area, you can see the variables and their values (Figure 3.11).

Figure 3.11. Stopped at a Breakpoint

Note that the variable i is currently 0.

Return your attention to the debugger bar. Four of the buttons above the variables view are for pausing (or continuing) and stepping over, into, and out of functions. Click the Continue button to execute another iteration of the loop. Click the Step-Over button to walk through the code line by line.

The gdb debugger, being a Unix thing, was designed to be run from a terminal. When execution is paused, the gdb terminal