objective-c - Xcode5 如何调试快速定位出错行

Question

、、、objectivec 2014-07-21 18:02:38.259 Sections[2962:70b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'must pass a class of kind UITableViewCell' *** First...

PHP中文网 · Answer

Ajoutez un point d'arrêt d'exception (Ajouter un point d'arrêt d'exception) dans le navigateur de point d'arrêt de Xcode, puis définissez la condition du point d'arrêt sur Exception: Object-C, afin qu'il puisse être interrompu avant que l'exception ne soit levée, et que vous puissiez voir la pile d'appels à ce moment-là.

Notez qu'il est préférable d'ouvrir ce point d'arrêt lorsque le code problématique est sur le point d'être exécuté, sinon il continuera à être perturbé par diverses exceptions.

PHP中文网 · Answer

Votre projet s'appelle Sections, n'est-ce pas ?
C'est ici que votre exception est levée :
4 Sections 0x000030eb -[BIDViewController searchDisplayController:didLoadSearchResultsTableView:] + 171
Le décalage de code de la méthode searchDisplayController de la classe BIDViewController est de 171 (presque les 170 caractères de cette méthode, presque les lignes 2 et 3. N'oubliez pas que 171 n'est pas un numéro de ligne ou quelque chose du genre).

À propos de l'analyse des exceptions iOS, c'est vraiment un casse-tête au début, car elle n'indique pas directement au développeur où l'exception est levée, et parfois il n'y a même pas de pile d'exceptions, et même s'il y a une pile d'exceptions, elle Il n'est pas facile de comprendre de quoi il s'agit. La signification, en particulier le numéro de décalage du code, est extrêmement trompeuse. Il existe généralement de nombreuses méthodes de débogage, et il faudrait une nuit entière pour toutes les aborder. Le point d'arrêt d'exception répondu par Huan Du en est un, et bien sûr il y a la méthode de visualisation d'impression d'assertion de journal, la définition de point d'arrêt symbolique, l'outil de débogage LLDB . Personnellement, je préfère toujours la méthode d'analyse de pile publiée dans votre question. Fondamentalement, le problème peut être déterminé en fonction du nom de la classe, du nom de la méthode et du décalage du code.

Concernant le rapport de stack, présentez brièvement la signification de son contenu :
Par exemple :
4 sections 0x000030eb -[BIDViewController searchDisplayController:didLoadSearchResultsTableView:] + 171
Il comprend un total de 5 parties : 4/Sections/0x000030eb/-[BIDVi...ew:]/171
Partie 1 : La pile génère le numéro de séquence. Plus le numéro de séquence est grand, plus il est précoce. le code est appelé
Partie 2 : Le framework (bibliothèque/projet) auquel appartient la méthode appelée. Par exemple, Sections est votre projet
; Partie 3 : L'adresse mémoire de la méthode appelante, qui est 0x000030eb
Partie 4 : Appeler le nom de la méthode, c'est très important, c'est-à-dire -[BIDViewController searchDisplayController:didLoadSearchResultsTableView:]
Partie 5 : Le décalage du code après l'appel de la méthode après compilation. Là encore, ce n'est pas le numéro de ligne, mais le décalage du code compilé, mais c'est fondamentalement le même que le nombre de caractères. Vous pouvez utiliser certains outils de texte pour compter votre. méthodes. Le décalage des caractères est une estimation approximative de la mauvaise ligne, et l'erreur générale est comprise entre 3 et 5 lignes.

Voici une petite astuce pour empêcher xcode de ne pas imprimer les journaux de pile :
Ajoutez @try@catch sur la méthode main dans main.m, comme ceci :

#import 

#import "AppDelegate.h"

int main(int argc, char* argv[])
{
    @try {
        @autoreleasepool
        {
            return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
        }
    }
    @catch (NSException* exception)
    {
        Log(@"Exception=%@
Stack Trace:%@", exception, [exception callStackSymbols]);
    }
}

Mais n'oubliez pas de supprimer le package try catch avant de publier l'application, cher ~~~

大家讲道理 · Answer

[UITableView registerClass:forCellReuseIdentifier:] Quelque chose s'est mal passé ici !