Why is EXC_BAD_ACCESS so unhelpful?

First let me say I come from a background in Flash/AS3, which I realize is not as strict about most things as iPhone/Objective-C.

I suspect my question actually applies to AS3 as well, but let me ask it as pertaining to Obj-c. Why is the error EXC_BAD_ACCESS, and others like it, so unhelpful? I realize that it normally means mismanagement of memory somewhere, but why can't it tell you more about the problem. For instance why doesn't it say "EXC_BAD_ACCESS, you tried to pass pointer suchAndSuch on line 123, however you're an idiot, because you released it on line 69 so it's not available anymore"?

I realize I can use the debugger to get more clues about where my error occurred, but many times this is only marginally helpful. For instance sometimes none of the messages in the stack/thread/whatever are even my code. Other times it is my code but on the top of the stack will be a message that has 4+ parameters, ok thanks debugger you narrowed it down to 4 possible pointers by why can't you just tell me which one!?

I'm guessing there's just some fundamental explanation that I missed because of the background I came from, not needing to worry about memory and such. Although there is an error that can happen a lot in AS3 development that is equally mysterious and along the same lines. "Error #1009: Cannot access a property or method of a null object refer开发者_如何转开发ence" which almost always means a variable you were expecting to be holding something is actually null. Why doesn't it tell me WHICH variable?!

Because Objective-C's runtime is quite small and simple, on purpose. You are practically coding a native app that's sitting right on the metal. The app has no idea why you got an EXC_BAD_ACCESS, all it knows is you tried to do something and the OS said no. EXC_BAD_ACCESS means you are attempting to access memory space that the OS did not give to you.

In Flash, Java, .NET, etc there is a hefty, powerful runtime sitting there running your app for you. It has a lot more context, and knows a lot more about what is going on. So a benefit of an environment like this is much clearer error messages, usually with a full stack trace.

Xcode can help you, look into zombifying your objects. Instead of deallocating them, they will become zombies and scream bloody murder if you try to use them again. Which helps pin down the cause.

You may also want to look at the Technical Q&A or the Debugging Magic

why can't it tell you more about the problem.

Because it doesn't have more information than that. Of course it could just keep track of all kinds of debug information, but that would slow the program down.

For instance why doesn't it say "EXC_BAD_ACCESS, you tried to pass pointer suchAndSuch on line 123, however you're an idiot, because you released it on line 69 so it's not available anymore"?

Think about what would have to happen in order to keep track of this all the time. Run it under a debugger that watches allocs and frees if you want to debug this.

Although there is an error that can happen a lot in AS3 development that is equally mysterious and along the same lines. "Error #1009: Cannot access a property or method of a null object reference" which almost always means a variable you were expecting to be holding something is actually null. Why doesn't it tell me WHICH variable?!

The runtime doesn't have your source code.

Basically, this boils down to "If you want to debug code, run it under a debugger".

Run it through a debugger. When you get the EXC_BAD_ACCESS exception, examine the backtrace, and at each frame inspect the values of the local variables. Also, place a few asserts here and there just to make sure values are what you expect them to be.