Console Debugger

Thomas =)

Bonjour,

Etant débutant sur Xcode, ma question vous paraà®tra surement stupide mais en développant mon application, je me heurte a une erreur :







Cependant, ayant des 10aines de classes dans mon projet, je voulais savoir s'il y avait moyen de connaitre le numéro de ligne et la classe ayant provoqué cette erreur, comme dans la console d'Eclipse par ex.



Sinon je vais devoir mettre des BreakPoint partout et avancer Pas a pas /wacko.png' class='bbc_emoticon' alt=' ' />

Céroce

À ma connaissance, la seule manière de le trouver est grâce à  une astuce: on ajoute une catégorie à  NSObject qui impléménte cette méthode -name.

Ensuite, tu n'as plus qu'à  mettre un point d'arrêt dans la méthode pour voir qui appelle. Comme tout objet hérite de NSObject, l'appel de -name sur NSString mènera à  cette méthode de debug.



Un conseil: commence quand même par lancer une analyse statique de ton code (Product > Analyze) et un petit coup d'Instruments/Zombies. 90% du temps, c'est une erreur de gestion mémoire.

yoann

Dans le navigateur du projet à  gauche dans Xcode 4 tu as un onglet Breakpoint avec un plus tout en bas qui te permet de rajouter des Breakpoint générique (pas associé à  une ligne). Si tu ajoute un Breakpoint d'exception en laissant tout par défaut tu aura un arrêt dès qu'une exception est levé.

Thomas =)

D'accord, merci pour les astuces /smile.png' class='bbc_emoticon' alt=':)' />

Céroce

@yoann: ça ne fonctionne pas pour ce genre d'exceptions. Tu peux effectivement mettre un point d'arrêt, mais en regardant la pile d'appels, tout ce que tu apprendras est que c'est un appel à  object_msg_send() qui a causé l'exception. Tu ne sauras pas quel objet a émis le message.

AliGator

Hello



Alors normalement après ce message, tu as la "Call stack at first throw", avec donc la pile d'appels. Tu peux donc savoir dans quel fichier ça a planté et à  quelle ligne.



Tu peux aussi mettre un "Exception Breakpoint" pour que ton programme s'arrête (breakpoint) juste avant le throw. Pour cela dans Xcode4 c'est très simple : dans le panneau de breakpoints (menu View > Navigators > Show Breakpoint Navigator) tout en bas de la liste des breakpoints existants (s'il y en a) tu cliques sur le bouton "+" et tu choisis "Add Exception Breakpoint". Ca va te permettre d'ajouter un breakpoint non pas sur une ligne donnée, mais juste avant que l'exception soit "throw".

Céroce

Soit dit en passant, j'utilise toujours la méthode évoquée plus haut, mais peut-être y a-t-il un autre moyen de savoir qui est l'émetteur du message ? Il est probable que le runtime le stocke quelque part.

yoann

Heu je suis désolé mais tu aura un arrêt lors de la création de l'exception par le runtime.

Thomas =)

C'est cette pile d'appel qui me permet d'identifier d'ou part l'erreur c'est ça ?

yoann

En partant du haut, cherche la première classe qui t'appartiens. À savoir PolicyEditViewController tableView:cellForRow...

Thomas =)

Ah je vois merci

Cependant, le 474 ne corresponds pas a la ligne puisque cette ligne ne correspond a rien

yoann

C'est un offset ça, t'as la méthode où ça merde et le nom de l'appel qui est fait pour faire planter, reste plus qu'à  faire ton job de développeur :-)

Céroce

'yoann' a écrit:

Heu je suis désolé mais tu aura un arrêt lors de la création de l'exception par le runtime.

Ben écoute, je ne sais pas, c'est peut-être un exemple simple pour lequel ça fonctionne? Mais je suis sûr de ce que j'avance, parce que sinon, je me m'amuserais pas à  créer une catégorie /crybaby.gif' class='bbc_emoticon' alt=' ' />

J'ai été obligé de le faire encore récemment avec un stagiaire.

yoann

'Céroce' a écrit:

Ben écoute, je ne sais pas, c'est peut-être un exemple simple pour lequel ça fonctionne? Mais je suis sûr de ce que j'avance, parce que sinon, je me m'amuserais pas à  créer une catégorie /crybaby.gif' class='bbc_emoticon' alt=' ' />

J'ai été obligé de le faire encore récemment avec un stagiaire.

Je m'en sert tout le temps... Et au pire si tu break dans un framework tu as toujours ta trace d'accessible pour remonter les séquences. L'avantage par rapport à  la simple trace écrite c'est que ton contexte mémoire est dispo pour voir ce qu'il s'est passé.

AliGator

Oui moi aussi je m'en sers toujours des Exception Breakpoint ça a toujours marché pour moi.

Jamais eu besoin de créer une catégorie sur NSObject pour ça jusque là .

JegnuX

bah après tu peux appeler une méthode du framework ou d'une lib tierce, qui attend un NSArray par exemple. Si tu lui donne un NSString et qu'en interne il fait un -objectAtIndex: par exemple, bah l'exception breakpoint sert pas à  grand chose je pense.

yoann

'JegnuX' a écrit:

bah après tu peux appeler une méthode du framework ou d'une lib tierce, qui attend un NSArray par exemple. Si tu lui donne un NSString et qu'en interne il fait un -objectAtIndex: par exemple, bah l'exception breakpoint sert pas à  grand chose je pense.

Comme je disais, si tu break dans un framework, tu as la trace pour remonter et avoir accès aux objets avec un peu de chance.

JegnuX

'yoann' a écrit:

Comme je disais, si tu break dans un framework, tu as la trace pour remonter et avoir accès aux objets avec un peu de chance.

Avec un peu de chance, oui.

LeChatNoir

hmmmmm. C'est étrange votre histoire... J'ai ajouté le breakpoint exception. Mais c'est une cata...

Il s'arrête régulièrement avec juste du code assembleur et quand je continue, ça continue normalement...



Ca m'inquiète ce truc... J'ai raison de m'inquiéter ? /smile.png' class='bbc_emoticon' alt=':)' />

JegnuX

Il se déclanche lorsqu'une exception est levée. Mais elle peut être traité via un @try{} @catch{}.



Du coup ça se passe ptet une librairie ou un framework. D'où le code assembleur.



Après, je dis peut etre une connerie. /biggrin.png' class='bbc_emoticon' alt=':D' />