What is the most hated error you have encounter when developing for the iPhone?

views:

430

answers:

+7 Q:

What is the most hated error you have encounter when developing for the iPhone?

Ever language has their famous and painfull errors. I will be fun to learn which errors earn this reputation when developing for the iPhone.

Please list yours!

I agree with GenericTypeTea If you can please list the error code/message and the cause to make for a more useful post.

+5 A:

I hate this one EXC_BAD_ACCESS (sometimes called EXEC_BAD_ACCESS)

Jamey McElveen 2009-07-07 18:16:34

http://stackoverflow.com/questions/1093916/debug-iphone-program-received-signal-excbadaccess

Troggy 2009-07-07 18:22:04

+6 A:

I hate all the device sync errors like

"iTunes could not connect to iPhone because an unknown error occurred (0xE8000025)"

Oh the humanity.

CJCraft.com 2009-07-07 18:20:45

+2 A:

I would say that the most frustrating error is actually the error that never happens. E.g. when you have an IBOutlet that has not been properly "plugged in", rather then getting a NullPointerException or some such, the code just silently does nothing. Why does sending a message to a "null" object not throw an exception? Grr....

Caffeine Coma 2009-07-07 18:26:49

Because the gain you get from not having to check for nil values everywhere (see: Java) is far vaster than the occasional misstep you get from having a message go to a nil object when you were expecting an object to be present.In consumer application development, code that keeps running is always preferred to code that crashes...

Kendall Helmstetter Gelner 2009-07-07 19:04:46

I could not disagree more. My development time is far more precious than the few nanoseconds it takes the JVM to detect a null reference.

Caffeine Coma 2009-07-07 19:10:48

Of course, it's Objective-C (more so than a JVM) that's taking the few extra nanoseconds to detect nils in order to special case that situation.

Daniel Dickison 2009-07-07 20:31:00

Not having to check for nils everywhere saves a tremendous amount of code and development time. If you truly want to guarantee that your IBOutlets are connected, I've found that using assert(yourOutlet != nil) for each outlet within awakeFromNib or similar does a good job of testing these.

Brad Larson 2009-07-07 20:38:00

I save way more developer time not having to check for nil, and to make use of that ability to intelligently write code that relies on passing messages to nil being OK, than I ever would from having an accidental nil reference cause an issue. Remember that Objective-C is at the core a message passing language, and not really C. I've been writing apps for the iPhone full time for over a year now and I have only had an object being nil cause an issue TWICE and both times were simple UI issues where something failed to show or an action failed to trigger, which I fixed in about a minute.

Kendall Helmstetter Gelner 2009-07-08 05:39:42

@Brad Larson- OK, so to detect whether my outlets are connected I have to write extra code... fine, but this "saves a tremendous amount of code" how? I know this is just a fundamental difference between a ObjC and Java-like languages. I understand where you are coming from, but I prefer the system to detect such situations as programming errors, and fail appropriately. I much prefer the system to fail and stop, than to continue on pretending that everything is fine, when in fact it is not. That's part of the normal debugging process you must do before you release your code.

Caffeine Coma 2009-07-08 15:02:50

+8 A:

Any error that has to do with code signing.

Mark Thalman 2009-07-07 18:27:16

This has improved in xcode 3.1.3, but I hate the amount of time I lose per day waiting for code signing.

Rhythmic Fistman 2009-07-07 19:05:41

+2 A:

Sending autorelease to an object you do not own, the app crashes with a EXC_BAD_ACCESS and you have no clue when did the object get released.

Marco Mustapic 2009-07-07 18:35:01

+1 A:

My most-hated error is when you download sample code to check something out, go to run it, and realize it's set to run on the device when you haven't changed the bundle identifier and the code isn't signed.

Jeff Kelley 2009-07-07 19:15:52

+7 A:

I particularly hate this error.

Thank you for submitting [application name here] to the App Store. We've reviewed the application and, consistent with the criteria in our approval process, we have chosen not to publish this application. As you know Apple reserves the right, in its sole discretion, to reject an application for any reason.

William Brendel 2009-07-07 19:19:19

This error never occurred to me. Nevertheless +1 because I'm so afraid of it.

Nikolai Ruhe 2009-07-07 19:56:16

I despise the error about "gcc exited with status code 1" and no other information.

Dave DeLong 2009-07-07 19:24:55

I love it and hate it that you can send messages to nil objects. I love it because you don't have to check for nil everywhere. I hate it because sometimes you're looking for that error for hours when all you do is send a message to a nil object. In that case an error would have been nice

drvdijk 2009-07-07 19:44:27

ansaurus

tags:

views:

answers:

What is the most hated error you have encounter when developing for the iPhone?

related questions