Skrevet av Reinder De Vries 6.August 2020 I Apputvikling, iOS

ett minutt går iOS-appen din bra I Xcode, og det neste har det håpløst krasjet Med EN KRYPTISK SIGABRT-Feil. Hva skjer!?

i denne opplæringen vil du lære:

• hvordan løse «Signal SIGABRT» – feilen I Xcode
• hvordan bruke noen av feilsøkingsverktøyene I Xcode
• HVA SIGABRT står for, og hva årsakene er
• 3 tilnærminger For å finne årsaken TIL SIGABRT

Klar? Kom igjen.

1. Hva Betyr» Tråd 1: Signal SIGABRT»?
2. Sjekk Utsalgssteder
3. Sjekk Stacktrace
4. Gjør Et Unntak Stoppunkt
5. Videre Lesing

Hva Betyr «Tråd 1: Signal SIGABRT»?

feilen SIGABRT står for «signal abort». Det er et signal som sendes av iOS-operativsystemet – til en løpende app, som umiddelbart vil avslutte appen på grunn av en kjøretidsfeil. Det betyr i hovedsak at appen din har krasjet…

Slik ser Det ut I Xcode:

i skjermbildet ser du noen ting:

• til venstre ser du en liste over tråder som kjørte da appen krasjet. Du ser at tråden som forårsaket krasj er hovedtråden, eller «Tråd 1».
• i redaktøren ser vi den fryktede Tråden 1: signal SIGABRT feil. Den har uthevet linje 12 i redaktøren, klassedefinisjonen av AppDelegate.
• nederst ser du nyttig feilsøkingsutgang. I dette tilfellet får du en stacktrace og en kryptisk feilmelding om ikke å være » key value coding-kompatibel.»

problemet MED SIGABRT-feilen er at den er for generisk. Xcode sier i utgangspunktet: «Se, appen din har krasjet, det er alt vi vet.»I de fleste TILFELLER AV SIGABRT-feilen får du lite informasjon om hva som forårsaket feilen.

før vi fortsetter, la OSS diskutere noen misforståelser OG vanlige fallgruver SIGABRT:

• SIGABRT-feilen har vanligvis ingenting å gjøre med AppDelegate klassedeklarasjon, selv om den fremhever den linjen I Xcode. Linjen er uthevet fordi det er den første kodelinjen i appen din. Ikke kast bort tiden din på å se iAppDelegate – klassen, med mindre du er helt sikker på at feilen er der inne.
• den stacktrace er en liste over funksjonssamtaler som fører opp til app krasjer. Det betyr ikke at kodelinjen som forårsaket feilen, er hvor som helst i stacktrace. Det er noen ganger, men i andre tilfeller fører stacktrace bare til koden som kvalt på en verdi du angir andre steder i din egen kode.
• ikke stirr deg blind på EN SIGABRT-feil. Det er en rasjonell, logisk årsak til feilen. Det er sannsynligvis en feil i din egen kode, og det er ingenting galt med det. Apps er ikke magi, ingen er ute etter å få deg, og bugs aldri vises ut av det blå. Ikke frustrer deg selv med tanker som » det gikk bra i går!»- det gjør det alltid, og nå gjør det ikke!

Nå som vi har etablert en grunnlinje, la oss komme til DEN første årsaken TIL SIGABRT.

Lær hvordan du bygger iOS-apper

Kom i gang med iOS 14 og Swift 5

Registrer deg for mitt iOS-utviklingskurs, og lær hvordan du bygger flotte iOS 14-apper Med Swift 5 og Xcode 12.

Sjekk Uttak

en vanlig årsak til «Signal SIGABRT» er en skrivefeil eller feil i uttak. Her er hva som skjedde:

Når Du bruker Interface Builder til å lage en visningskontroller, vil app vil bruke xib-filen til å generere Visningen kontrolleren ui når appen din kjører(grovt sett). På dette punktet vil det også koble uttak FRA XIB til egenskapene til view controller-klassen.

hvis du har endret navnet på en outlet-egenskap, finner ikke appen den lenger. Og på grunn av det vil det kaste et unntak. Hva som forårsaker SIGABRT-feilen, håndterer ikke det unntaket.

Her er hva Som ser ut I Xcode:

Se Hva som skjer? Egenskapen kalles otherButton, men uttaket kalles fortsatt knapp. På et tidspunkt endret vi uttaket-fordi det nye navnet er bedre-og forvirret appen, noe som gjorde det krasj.

på toppen av stacktrace ser vi også en annen anelse:

Terminating app due to uncaught exception 'NSUnknownKeyException', reason: ': this class is not key value coding-compliant for the key button.

hva betyr Det? Appen forteller oss på dette punktet at visningskontrolleren ikke er nøkkelverdikoding kompatibel for nøkkelen button. Dette betyr at den ikke finnerbutton – egenskapen på visningskontrolleren. Og det er sant, fordi vi har omdøpt det.iOS bruker en mekanisme som kalles nøkkelverdikoding for å inspisere egenskapene en visningskontroller har, slik at den kan bruke disse egenskapene til å referere TIL UI-elementer den har opprettet basert PÅ XIB.

Hvordan løser du feilen på dette punktet? Du kan bruke 2 tilnærminger:

1. du omdøper eiendommen tilbake til sitt opprinnelige navn
2. du fjerner uttakstilkoblingen i Interface Builder, og kobler den til igjen ved hjelp av det nye uttaksegenskapsnavnet

La oss gå videre!

Sjekk Stacktrace

I Mange tilfeller Xcode vil ikke vise deg noen nyttige feilmeldinger FOR EN SIGABRT krasj. Når det skjer, er det nyttig å vite noen feilsøkingskommandoer, for eksempel bt.

Xcode har et integrert feilsøkingsmiljø kalt LLDB. Det er det du ser nederst I Xcode når appen kjører, Konsollen eller feilsøkingsområdet. Du ser ofte feilsøkingsmeldinger her, men visste du at du også kan bruke den til å legge inn kommandoer?

neste gang appen krasjer, kan du prøve å skrive help I LLDB. Slik:

du vil se at MANGE AV LLDB-kommandoene samsvarer direkte med handlinger du kan ta med debuggeren, for eksempel å sette avbruddspunkter, gå over kodelinjer og inspisere kjøretidsverdier.

en kommando er spesielt nyttig. Du kan skrive inn bt for å se den nåværende anropsstakken(også kalt » backtrace «eller»stacktrace»). Dette er en liste over alle funksjoner som kjørte opp til gjeldende krasj. Dette sporet inneholder vanligvis funksjonen som forårsaket en feil.

her, sjekk ut stacktrace av en typisk Indeks utenfor rekkevidde feil. I skjermbildet nedenfor har vi bevisst forårsaket feilen ved å få index 99 fra en matrise som bare har 4 elementer. Når appen krasjer ,kanbt fortelle oss hvilken linje med kode som forårsaket feilen.

kan du se følgende informasjon i stacktrace?

• den fornærmende koden er på linje 21 avViewController.swift, inne iviewDidLoad() funksjon
• du kan til og med se at vi brukte subscript «getter» avArray
• før krasj en hel haug basert på informasjonen vi fikk med bt, kan vi finne den fornærmende linjen i koden vår og fikse den. Xcode hjalp oss allerede i dette tilfellet ved å markere feilen i redaktøren. I noen scenarier vil du ikke ha slik flaks, og da kan det være nyttig å bruke kommandoenbt.

  en siste ting: du kan inspisere verdier under kjøring med kommandoenprint. I scenariet ovenfor ville skrive print names ha produsert denne utgangen:

  () $R0 = 4 values { = "Ford" = "Arthur" = "Zaphod" = "Trillian"}

  for utskrift av komplekse objekter, bruk po. Fantastisk!

  Husk at en stacktrace går utenfor inn. Bunnen av stabelen spor viser øverste nivå funksjonssamtaler, og jo høyere opp stabelen du går, jo dypere samtaler gå i. Den siste, siste, dypeste nivå samtalen er på toppen av stabelen.

  Gjør Et Avbruddspunkt for Unntak

  du kan bruke avbruddspunkter for å stoppe kjøringen av koden din på en bestemt linje. På det tidspunktet kan du deretter inspisere verdier og gå gjennom funksjoner.

  et avbruddspunkt for unntak utløses når det oppstår et unntak i koden din. I stedet for å angi hvilken linje avbruddspunktet utløses, instruerer du debugger å stoppe kjøring av kode for unntak.

  unntaksavbruddspunkter er nyttige for å inspisere koden når det oppstår et unntak. Du kan se hvilken linje med kode kastet unntaket, og du kan inspisere verdier i koden din på det tidspunktet. Noen unntak er forårsaket av feil eller ugyldige tilstander i appen din, så unntaksavbruddspunkter er nyttige for å finne og fikse disse feilene.

  slik angir du et avbruddspunkt for unntak:

  1. Gå til Stoppunkt navigator I Xcode, ved hjelp av fanene til venstre
  2. Klikk nederst til venstre +-knappen og velg Unntak Stoppunkt
  3. La standardinnstillingene som de er (selv om de er nyttige for å tilpasse)
  4. Kjør koden

  

  når et unntak kastes, stopper utførelsen av appen din. Du kan nå bruke debugger å inspisere verdier, gå gjennom koden, og bruke LLDB kommandoer. Når Det er mulig, Vil Xcode ta deg til kodelinjen som forårsaket unntaket.

  Husk at et unntak ikke nødvendigvis krasje din app! Så når unntaksavbruddspunktet er aktivert, og et unntak oppstår, stoppes appen din. Stoppe kode med et stoppunkt er ikke det samme som en appkrasj, så ikke la det forvirre deg.

  for eksempel vil et unntaksavbruddspunkt bli utløst av et unntak Med Utilfredsstillende begrensninger, men det vil ikke krasje appen din. Bruk unntaksbruddspunktet for å samle ekstra informasjon FOR SIGABRT-krasj, og deaktiver den når DU har løst feilen (til den trengs igjen).

  

  Lær hvordan du bygger iOS-apper

  Kom i gang med iOS 14 og Swift 5

  Registrer deg for mitt iOS-utviklingskurs, og lær hvordan du bygger flotte iOS 14-apper Med Swift 5 og Xcode 12.

  Videre Lesing

  sigabrt-feilen er ganske kryptisk, og kan vise seg vanskelig å løse. Hvorfor Kan Ikke Xcode bare gi nyttige feilmeldinger? Det korte svaret er at det er så mange bevegelige deler i iOS-utvikling At Xcode ikke alltid kan bestemme årsaken til et krasj. Xcode vet ikke at du feilaktig endret navnet på et uttak. Det vet bare at ved tilkobling av uttaket ble noen kode påkalt, og det forårsaket et unntak.

  Dette betyr at du alltid vil se en feil som er så nær grunnårsaken som mulig. Det beste du kan gjøre er å gjøre mange feil, dekryptere mange feilmeldinger, og bli bedre kjent med dem. Og det du har lært i denne opplæringen, er hvordan du finner OG løser SIGABRT-feilen!

  vil du vite mer? Sjekk ut disse ressursene:

  • Kom I Gang Med Feilsøking I Xcode
  • Forstå Feilen «Ukjent Velger Sendt Til Forekomst» I Xcode
  • Forstå «Uventet funnet null mens du pakker ut En Valgfri verdi» Feil
  • Forstå Feilen «Bruk Av Uløst Identifikator» I Xcode
  • Off-By-One Feil I Swift Programmering
  • Feilhåndtering I Swift Med Do-Try-Catch