在Objective-C和Xcode中抛出的调试异常 [英] Debugging exception thrown in Objective-C and Xcode

问题描述

我是Microsoft的长期开发人员，并且是使用Xcode进行iPhone开发的新手.因此，我正在阅读一本书，并通过示例尝试自学如何使用Objective-C编写iPhone应用程序.到目前为止，一切都很好，但是，有时我会在运行时遇到通用的"objc_exception_throw"消息.发生这种情况时，很难找到此异常的来源.经过反复试验，我找到了答案.参数之一拼写错误.

I am a long time Microsoft developer and I am new to iPhone development using Xcode. So, I am reading a book and going through examples trying to teach myself how to write an iPhone application using Objective-C. All has been good so far, however, once in a while I run into the generic 'objc_exception_throw' message at runtime. When this happens, the source of this exception is very difficult to find. After some trial and error I found my answer. One of the parameters was misspelled.

正如您在下面看到的那样，我通过省略按钮中的第二个't'拼写了'otherButtonTitles'参数.

As you can see below, I misspelled the 'otherButtonTitles' parameter by leaving out the second 't' in button.

UIAlertView *alert = [[UIAlertView alloc] 
                      initWithTitle:@"Date and Time Selected" 
                      message:message 
                      delegate:nil
                      cancelButtonTitle:@"Cancel"
                      otherButonTitles:nil];

之所以花时间去寻找原因是因为代码构建成功.这是Objective-C编译器的正常行为吗?当我遇到这样的常见语法错误时，我习惯于.NET编译器中的构建失败.当我犯这些错误时，是否可以更改编译器设置以使构建失败?

The reason this took me time to find is that the code built successfully. Is this normal behavior for the Objective-C compiler? I am used to having the build fail in the .NET compiler when I make a common syntax error like this. Is there a compiler setting I can change to make the built fail when I make these mistakes?

推荐答案

首先，打开~/.gdbinit(这是主目录中名为.gdbinit的文件-是的，以点开头)并将其放入其中:

First and foremost, open ~/.gdbinit (that's the file called .gdbinit in your home directory - yes, starts with a dot) and put this in it:

fb -[NSException raise]
fb objc_exception_throw
fb malloc_error_break

这将使用三个默认断点初始化GDB，当它们出现时，GDB将暂停您的应用程序并向您显示堆栈跟踪.它与Xcode很好地集成在一起，因此一旦某个地方发生异常或malloc失败，您就可以通过单击堆栈跟踪元素来很好地浏览代码.

That'll initialize GDB with three default breakpoints, when they occur, GDB will halt your application and show you the stack trace. This is very well integrated with Xcode so you'll be able to nicely walk through your code by clicking stack trace elements as soon as an exception occurs somewhere or a malloc fails.

然后，打开项目上的Get Info面板(或选择您的项目(Groups & Files中的顶部项)并点击cmd-i)，转到Build选项卡并将项目的Base SDK设置为Device - iPhone OS [someversion].一直滚动到底部，找到GCC 4.0 - Warnings部分.那里;根据您的喜好打开尽可能多的警告，但是请确保打开Treat Warnings as Errors(这等效于GCC_TREAT_WARNINGS_AS_ERRORS).就个人而言，我将其设置为:

Then, open the Get Info panel on your project (or select your project (top item in the Groups & Files) and hit cmd-i), go to the Build tab and set your project's Base SDK to Device - iPhone OS [someversion]. Scroll all the way to the bottom and find the GCC 4.0 - Warnings section. There; turn on as many warnings as you feel comfortable with, but make sure to turn on Treat Warnings as Errors (this is the equivalent of GCC_TREAT_WARNINGS_AS_ERRORS). Personally, I have it set to this:

_{(来源: lyndir.com )}

_{(source: lyndir.com)}

您现在应该对大多数在代码中可能做错的事情得到编译器警告，并且编译器只有在修复它们之后才允许您运行代码.当事情真的越过编译器的鼻子时，您应该能够在方便的地方轻松找到GDB中断的问题.

You should now be getting compiler warnings for most things you can do wrong in code and the compiler won't let you run the code until you fix them. When things do get past the compiler's nose, you should be able to find the problem easily with GDB breaking at a convenient spot.

您还应该查看NSZombie*.这些是环境变量，对于在内存分配或访问情况不佳的情况下提早中断非常有用.例如; NSZombieEnabled什么都不会真正释放；在dealloc上，它会被_NSZombie覆盖，并且如果您尝试再次访问此已分配的内存(取消引用已分配的指针)，则会在GDB中遇到一些麻烦，而不是像正常情况下那样进行调用，只会被发出基于随机数据(当然，这不是您想要的).有关此的更多信息，请参见

You should also look into NSZombie*. These are environment variables that are very handy for early breaking on bad memory allocation or access situations. For instance; wih NSZombieEnabled nothing will truly be released; on dealloc it'll get overwritten with _NSZombie and should you try to access this dealloced memory again (dereferencing a dealloced pointer) you'll get something to break on in GDB, instead of the call going through like normal, only being issued on random data (which, of course, isn't what you wanted). For more info on this, see http://www.cocoadev.com/index.pl?NSZombieEnabled.

这篇关于在Objective-C和Xcode中抛出的调试异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！