skrevet af Reinder de Vries den 6.August 2020 i appudvikling, iOS

et minut kører din iOS-app fint i kode, og den næste er den håbløst styrtet ned med en kryptisk sigabrt fejl. Hvad sker der!?

i denne tutorial vil du lære:

• Sådan løses fejlen “Signal SIGABRT” i kode
• Sådan bruges nogle af fejlfindingsværktøjerne i kode
• hvad SIGABRT står for, og hvad dens årsager er
• 3 tilgange til at finde årsagen til SIGABRT

klar? Lad os gå.

1. hvad betyder” tråd 1: Signal SIGABRT”?
2. Tjek dine forretninger
3. kontroller Stacktrace
4. lav en undtagelse Breakpoint
5. yderligere læsning

Hvad betyder” tråd 1: Signal SIGABRT”?

fejlen SIGABRT står for”signalafbrydelse”. Det er et signal, der sendes af iOS-operativsystemet-til en kørende app, som straks afslutter appen på grund af en runtime-fejl. Det betyder i det væsentlige, at din app er gået ned…

Her er hvordan det ser ud i kode:

i skærmbilledet ser du et par ting:

• til venstre ser du en liste over tråde, der løb, da appen styrtede ned. Du ser, at tråden, der forårsagede nedbruddet, er hovedtråden eller “tråd 1”.
• i editoren ser vi den frygtede tråd 1: signal SIGABRT fejl. Det har fremhævet linje 12 i editoren, klassedefinitionen af AppDelegate.
• nederst kan du se nyttige debug output. I dette tilfælde får du en stacktrace og en kryptisk fejlmeddelelse om ikke at være “key value coding-compliant.”

problemet med sigabrt-fejlen er, at den er for generisk. “Se, din app er gået ned, det er alt, hvad vi ved.”I de fleste tilfælde af sigabrt-fejlen får du lidt information om, hvad der har forårsaget fejlen.

før vi fortsætter, lad os diskutere et par misforståelser og almindelige faldgruber af SIGABRT:

• sigabrt-fejlen har normalt intet at gøre med AppDelegate klassedeklaration, selvom den fremhæver denne linje i kode. Linjen er fremhævet, fordi det er den første linje kode i din app. Spild ikke din tid på at kigge i AppDelegate klassen, medmindre du er helt sikker på, at fejlen er derinde.
• stacktrace er en liste over funktionsopkald, der fører op til, at appen går ned. Det betyder ikke, at kodelinjen, der forårsagede fejlen, er overalt i stacktrace. Det er nogle gange, men i andre tilfælde fører stacktrace blot til den kode, der kvalt på en værdi, du angiver andetsteds i din egen kode.
• må ikke stirre dig selv blind på en sigabrt fejl. Der er en rationel, logisk årsag til fejlen. Det er nok en fejl i din egen kode, og der er ikke noget galt med det. Apps er ikke magiske, ingen er ude for at få dig, og bugs vises aldrig ud af det blå. Må ikke frustrere dig selv med tanker som “det løb fint i går!”– det gør det altid, og nu gør det ikke!

nu hvor vi har etableret en baseline, lad os komme til den første årsag til SIGABRT.

Tjek dine forretninger

en almindelig årsag til “Signal SIGABRT” er en skrivefejl eller fejl i dine forretninger. Her er hvad der skete:

• du oprettede en ny visningskontroller i Interface Builder og satte den op med et par UI-elementer som knapper og etiketter
• du tilsluttede disse UI-elementer til din kode ved hjælp af outlet-egenskaber, hvilket skaber en forbindelse mellem en egenskab for din visningskontroller og UI-elementet i Interface Builder
• på et tidspunkt ændrede du navnet på den oprindelige outlet-egenskab, og din app begyndte at gå ned med en sigabrt-fejl

Når du bruger Interface Builder til at oprette en visningskontroller, vil din app bruge filen til at generere visningskontrollerens brugergrænseflade når din app kører (groft sagt). På dette tidspunkt vil det også forbinde stikkontakter fra KBIB til Egenskaber for visningskontrollerklassen.

Hvis du har ændret navnet på en outlet-ejendom, kan din app ikke finde den længere. Og på grund af det vil det kaste en undtagelse. Hvad der forårsager sigabrt-fejlen, håndterer ikke denne undtagelse.

Sådan ser det ud i kode:

se hvad der sker? Ejendommen hedder otherButton, men stikkontakten kaldes stadig knap. På et tidspunkt ændrede vi stikkontakten – fordi det nye navn er bedre – og forvirrede appen, hvilket fik det til at gå ned.

øverst på stacktrace ser vi også en anden ledetråd:

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

hvad betyder det? Appen fortæller os på dette tidspunkt, at visningskontrolleren ikke er nøgleværdikodningskompatibel for nøglen button. Dette betyder, at den ikke kan finde button egenskaben på visningskontrolleren. Og det er sandt, fordi vi har omdøbt det.

iOS bruger en mekanisme kaldet key value coding til at inspicere de egenskaber, en visningscontroller har, så den kan bruge disse egenskaber til at henvise til UI-elementer, den har oprettet baseret på den.

hvordan løser du fejlen på dette tidspunkt? Du kan bruge 2 tilgange:

1. du omdøber ejendommen tilbage til dets oprindelige navn
2. du fjerner outlet-forbindelsen i Interface Builder og tilslutter den igen ved hjælp af det nye outlet-egenskabsnavn

lad os gå videre!

kontroller Stacktrace

i mange tilfælde vil koden ikke vise dig nogen nyttige fejlmeddelelser til et sigabrt-nedbrud. Når det sker, er det nyttigt at kende et par fejlfindingskommandoer, såsom bt.har en integreret debugging miljø kaldet LLDB. Det er, hvad du ser i bunden af koden, når din app kører, konsollen eller debug outputområdet. Du ser ofte fejlretningsmeddelelser her, men vidste du, at du også kan bruge den til at indtaste kommandoer?

næste gang din app går ned, prøv at skrive help i LLDB. Sådan her:

du vil se, at mange af lldb-kommandoerne direkte svarer til handlinger, du kan tage med debuggeren, såsom indstilling af breakpoints, stepping over linjer med kode og inspektion af runtime-værdier.

en kommando er særlig nyttig. Du kan indtaste bt for at se den aktuelle opkaldsstak (også kaldet” backtrace “eller”stacktrace”). Dette er en liste over alle funktioner, der løb op til det aktuelle nedbrud. Dette spor omfatter typisk den funktion, der forårsagede en fejl.

her, tjek stacktrace af en typisk indeks uden for rækkevidde fejl. I skærmbilledet nedenfor har vi bevidst forårsaget denne fejl ved at få indeks 99 fra et array, der kun har 4 elementer. Når appen går ned, kan bt fortælle os, hvilken kodelinje der forårsagede fejlen.

kan du se følgende oplysninger i stacktrace?

• den krænkende kode er på linje 21 af ViewController.swift, inde i viewDidLoad() funktion
• du kan endda se, at vi brugte abonnementet “getter” af Array
• før nedbruddet en hel del af den”div flok visning controller-relaterede funktionsopkald blev foretaget

baseret på de oplysninger, vi fik med bt, kan vi finde den krænkende linje i vores kode og rette den. Kcode har allerede hjulpet os i dette tilfælde ved at fremhæve fejlen i editoren. I nogle scenarier har du ikke sådan held, og så kan det være nyttigt at bruge kommandoen bt.

en sidste ting: du kan inspicere værdier ved kørsel med kommandoenprint. I ovenstående scenario ville skrive print names have produceret denne output:

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

til udskrivning af komplekse objekter, Brug po. Fedt!

lav en undtagelse Breakpoint

Du kan bruge breakpoints til at stoppe udførelsen af din kode på en bestemt linje. På det tidspunkt kan du derefter inspicere værdier og gå gennem funktioner.

en undtagelse breakpoint udløses, når der opstår en undtagelse i din kode. I stedet for at angive på hvilken linje breakpoint udløses, du instruere debugger at standse kode udførelse for undtagelser.

undtagelse breakpoints er nyttige til inspektion af koden, når en undtagelse opstår. Du kan se, hvilken kodelinje der kastede undtagelsen, og du kan inspicere værdier i din kode på det tidspunkt. Nogle undtagelser skyldes fejl eller ugyldige tilstande i din app, så undtagelsesbrudspunkter er nyttige til at finde og rette disse fejl.

sådan kan du indstille et undtagelsesbrudspunkt:ved at bruge fanerne til venstre

Klik på knappen nederst til venstre +-og vælg undtagelse Breakpoint

Forlad standardindstillingerne som de er (selvom de er nyttige til at tilpasse)

Kør din kode

når en undtagelse kastes, stopper udførelsen af din app. Du kan nu bruge debuggeren til at inspicere værdier, gå gennem koden og bruge lldb-kommandoer. Når det er muligt, tager vi dig til den kodelinje, der forårsagede undtagelsen.

Husk, at en undtagelse ikke nødvendigvis går ned i din app! Så, når undtagelsen breakpoint er aktiveret, og en undtagelse opstår, din app er stoppet. At stoppe kode med et breakpoint er ikke det samme som et app-nedbrud, så lad det ikke forvirre dig.

for eksempel vil en undtagelse breakpoint blive udløst af en utilfreds begrænsninger undtagelse, men det vil ikke gå ned din app. Brug undtagelses breakpoint til at indsamle ekstra information til SIGABRT-nedbruddet, og deaktiver det derefter, når du har løst fejlen (indtil den er nødvendig igen).

yderligere læsning

sigabrt-fejlen er ret kryptisk og kan vise sig vanskelig at løse. Hvorfor kan ikke Kcode bare give nyttige fejlmeddelelser? Det korte svar er, at der er så mange bevægelige dele i iOS-udviklingen, at kode ikke altid kan bestemme årsagen til et nedbrud. Kcode ved ikke, at du fejlagtigt ændrede navnet på en stikkontakt. Det ved kun, at der ved tilslutning af stikkontakten blev påberåbt en kode, og det forårsagede en undtagelse.

dette betyder, at du altid vil se en fejl, der er så tæt på grundårsagen som muligt. Det bedste du kan gøre er at lave mange fejl, dekryptere mange fejlmeddelelser og lære dem bedre at kende. Og hvad du har lært i denne tutorial, er, hvordan du finder og løser sigabrt-fejlen!

vil du vide mere? Tjek disse ressourcer:

• kom i gang med fejlsøgning i kode
• forstå fejlen “ukendt vælger sendt til forekomst” i kode
• forstå fejlen “uventet fundet nul, mens du pakker en valgfri værdi ud”
• forstå fejlen “brug af uløst identifikator” i kode
• Off-By-one fejl i Hurtig programmering
• fejlhåndtering i hurtig med Do-Try-Catch