Xcode lance une exception dans Main () dans iOS 8 avec un point d’arrêt «toutes les exceptions»

J’utilise Xcode 6 (GM, je n’ai pas téléchargé de betas) et je développe des applications pour iOS 7+. Pour tous mes projets, je viens d’ouvrir les mêmes projets sur lesquels je travaillais dans Xcode 5.

Dans le navigateur Breakpoint, le point d’arrêt All Exceptions activé. Il est réglé sur Break: On Throw . Maintenant, chaque fois que je lance mon application (que ce soit sur un périphérique ou dans un simulateur), elle arrête l’exécution sur la ligne return UIApplicationMain(argc, argv, nil, NSSsortingngFromClass([AppDelegate class])); dans la fonction main() .

Si j’appuie sur Play pour continuer l’exécution du programme deux fois, le programme fonctionne correctement. Cela ne m’empêche pas de travailler, mais il est ennuyeux de devoir exécuter manuellement l’exécution à chaque fois et de réinitialiser mes éditeurs.

J’aime les comportements que j’ai mis en place dans Xcode (en prenant l’éditeur actuel à l’endroit où l’exécution s’est arrêtée), et avoir ce point d’arrêt All Exceptions est important. (Donc je ne veux pas les changer)

En exécutant le même code, avec les mêmes environnements, pour une cible iOS 7 (encore une fois, périphérique ou simulateur), l’exception n’est pas levée.

Quel indice pourrait causer ce comportement étrange?

Comme indiqué dans les commentaires, vous devez désactiver les exceptions C ++ en modifiant votre point d’arrêt Toutes les exceptions .

Pour ce faire, cliquez avec le bouton droit de la souris sur votre point d’arrêt et modifiez Exception de Tous en Objective-C :

changer tout en Objective-C

Les exceptions dans le code C ++ font partie des fonctionnalités normales de l’application. Cependant, le point d’arrêt d’exception n’est pas pris en charge, mais toutes les exceptions levées, même si elles sont traitées ultérieurement, d’où l’arrêt de l’exécution.

TLDR; Dans mon cas, la cause du problème était l’absence de fonts.

J’ai aussi eu ce problème. Alors que @Johnnywho a raison de laisser le sharepoint contrôle des exceptions d’Objective-C uniquement, arrête le comportement indésirable, il n’explique toujours pas la cause réelle, pourquoi il s’exécute sans exception sur iOS7 et pourquoi cela ne se produit que sur certains projets.

C’est pourquoi j’ai poursuivi et disséqué l’un de mes projets dans lequel j’avais ce problème, jusqu’à ce que je puisse en trouver la cause. Je suppose qu’il pourrait y avoir plus d’une cause pour ce comportement, mais dans mon cas, il manquait des fonts personnalisées.

Moyen rapide de le tester:

  1. Lancer un nouveau projet à vue unique

  2. Activer le point d’arrêt sur toutes les exceptions, y compris C ++ (points d’arrêt / + / Ajouter un point d’arrêt d’exception)

  3. Faites glisser dans le projet une police personnalisée (autorisez la copie et vérifiez la cible pour l’append)

  4. Ajouter une étiquette à la vue dans le contrôleur de vue principale

  5. Choisissez la police personnalisée pour votre étiquette (sur Xcode 6+, elle devrait apparaître dans le sélecteur de fonts dès que vous la faites glisser dans le projet).

  6. Exécutez l’application et confirmez que vous voyez l’étiquette dans votre police personnalisée (il semble que nous n’avons plus besoin d’append le nom du fichier de police dans Info.plist pour la clé “Polices fournies par l’application”, si la police personnalisée a été utilisé dans un storyboard de xib de l’application).

  7. Supprimez maintenant la police personnalisée de votre projet (en décochant la relation cible ou en la supprimant dans les parameters de cible / Construire des phases / Copier des ressources de regroupement).

  8. Supprimer l’application de votre appareil ou de votre sim (pour supprimer le fichier de police du lot d’applications)

  9. Produit / Propre

  10. Exécutez l’application à nouveau (maintenant l’étiquette a toujours la référence à la police personnalisée, mais l’application n’a pas le fichier). Vous devriez remarquer l’exception mystérieuse si vous exécutez sur iOS8.

  11. Exécutez l’application sur l’appareil avec iOS7 ou sim avec iOS7 (pour cela, vous devez remplacer iOS Deployment Target par iOS7). Bien que l’étiquette ne montre pas la police personnalisée, il n’y aura pas d’exception.

  12. Ajoutez le fichier de police à la cible et le point d’arrêt ne s’arrête plus.

Donc, ma conclusion est que sur iOS8, les fonts manquantes provoquent une exception C ++ alors que sur iOS7 elles ne le font pas, d’où le déclenchement du point d’arrêt.

Une exception similaire (et un déclencheur de point d’arrêt) peut également être provoquée par un nom de fichier de police incorrectement écrit dans le fichier Info.plist sous la clé “Polices fournies par l’application”.

Je viens de résumer les réponses précédentes qui m’ont aidé à résoudre le problème.

Problème: Lorsque vous ajoutez une police personnalisée et que vous la supprimez apparemment (remplacez-la) quelque part dans le projet est toujours sa référence et le point d’arrêt s’arrête plusieurs fois au point d’arrêt principal de la librairie C ++ s’arrête dans iOS 8.

Solutions

1) Recherchez dans le projet et supprimez (remplacez) toutes les références à ces fonts. Dans certaines plumes, sous-modules, etc…

2) Si vous ne pouvez pas réparer partout (les lib ex en lecture seule les utilisent) ou si le problème persiste après la solution 1, ajoutez ces anciennes fonts au projet

3) Ignorer – C ++ libère donc changez l’exception de point d’arrêt de “All” à “Objective-C” seulement

Xcode 9, il y a parfois des exceptions qui sont lancées, mais iOS les rattrape gracieusement. CA aidera

entrer la description de l'image ici

entrer la description de l'image ici

la source

pour mon cas, il s’agissait d’un atsortingbut défini par l’utilisateur dans nib

J’ai eu le même problème, le problème était que j’ai ajouté des fichiers d’interface d’un autre projet qui a une police différente. Il suffit de les trouver et de les supprimer.