›

Console Debugger

Thomas =)Thomas =) Membre
dans Xcode et Developer Tools #1
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 :



erreurp.png



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 image/wacko.png' class='bbc_emoticon' alt=' :* ' />

Réponses

  • CéroceCéroce Membre, Modérateur
    avril 2012 modifié #2
    À 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.
  • yoannyoann Membre
    #3
    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 =)Thomas =) Membre
    #4
    D'accord, merci pour les astuces image/smile.png' class='bbc_emoticon' alt=':)' />
  • CéroceCéroce Membre, Modérateur
    avril 2012 modifié #5
    @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.
  • AliGatorAliGator Membre, Modérateur
    #6
    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éroceCéroce Membre, Modérateur
    #7
    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.
  • yoannyoann Membre
    #8
    Heu je suis désolé mais tu aura un arrêt lors de la création de l'exception par le runtime.



    capturedcran20120423113.png
  • Thomas =)Thomas =) Membre
    #9
    piledappel.png





    C'est cette pile d'appel qui me permet d'identifier d'ou part l'erreur c'est ça ?
  • yoannyoann Membre
    #10
    En partant du haut, cherche la première classe qui t'appartiens. À savoir PolicyEditViewController tableView:cellForRow...
  • Thomas =)Thomas =) Membre
    avril 2012 modifié #11
    Ah je vois merci

    Cependant, le 474 ne corresponds pas a la ligne puisque cette ligne ne correspond a rien :/
  • yoannyoann Membre
    #12
    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éroceCéroce Membre, Modérateur
    avril 2012 modifié #13
    '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 image/crybaby.gif' class='bbc_emoticon' alt=' :'( ' />

    J'ai été obligé de le faire encore récemment avec un stagiaire.
  • yoannyoann Membre
    #14
    '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 image/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é.
  • AliGatorAliGator Membre, Modérateur
    #15
    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à .
  • JegnuXJegnuX Membre
    #16
    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.
  • yoannyoann Membre
    #17
    '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.
  • JegnuXJegnuX Membre
    #18
    '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.
  • LeChatNoirLeChatNoir Membre, Modérateur
    #19
    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 ? image/smile.png' class='bbc_emoticon' alt=':)' />
  • JegnuXJegnuX Membre
    #20
    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. image/biggrin.png' class='bbc_emoticon' alt=':D' />
Connectez-vous ou Inscrivez-vous pour répondre.