Trotz Swifts elegantem Design sind System-Fehlermeldungen oft kryptisch und wenig hilfreich. Statt mich nur zu beschweren, habe ich ErrorKit entwickelt – ein Tool, das diese Meldungen auf menschenfreundliche Beschreibungen abbildet. Aber Apples gesamtes Ökosystem abzudecken, ist eine zu große Aufgabe für eine einzelne Person – das muss ein Community-Projekt werden.
In diesem Beitrag teile ich die Grundlage, die ich für verbesserte Fehlerbeschreibungen geschaffen habe, und lade dich ein, gemeinsam mit mir ein umfassendes Wörterbuch benutzerfreundlicher Fehlermeldungen für Swift-Entwickler zu erstellen.
Das Problem mit System-Fehlermeldungen
Schauen wir uns ein paar reale Beispiele unhilfreicher System-Fehlermeldungen an:
// Dateisystem-Fehler
"The file couldn't be opened because it doesn't exist."
// Bessere Meldung: "The file 'report.pdf' could not be found. Please verify the file name and location."
// Core Data-Fehler
"The operation couldn't be completed. (Cocoa error 133000.)"
// Bessere Meldung: "The database has a validation error. One or more required fields are empty or have invalid values."Diese Standard-Meldungen haben mehrere Probleme:
Sie sind oft zu technisch für Endnutzer
Ihnen fehlt der Kontext, was gerade versucht wurde
Sie bieten selten Vorschläge, wie sich das Problem lösen lässt
Sie sind manchmal schlicht falsch oder irreführend
Sie können Implementierungsdetails preisgeben, die Nutzer gar nicht sehen sollten
Apple hat tausende Fehlercodes über Dutzende Frameworks verteilt, und viele davon existieren seit Jahrzehnten. Neuere APIs wurden zwar verbessert, aber viele ältere Frameworks liefern nach wie vor Meldungen, die für Entwickler gedacht sind – nicht für Nutzer.
Die Lösung: Community-kuratierte Fehlerzuordnungen
ErrorKit stellt eine Funktion namens userFriendlyMessage(for:) bereit, die System-Fehler auf hilfreichere Meldungen abbildet:
do {
let data = try Data(contentsOf: url)
// Daten verarbeiten...
} catch {
// Statt die Standard-Meldung anzuzeigen
// showAlert(error.localizedDescription)
// Eine verbesserte Meldung anzeigen
showAlert(ErrorKit.userFriendlyMessage(for: error))
}Unter der Haube analysiert diese Funktion den Fehler und gibt eine bessere Beschreibung zurück, basierend auf einer wachsenden Sammlung bekannter Fehlertypen:
// Beispiel aus ErrorKits Implementierung
enum FoundationErrorMapper: ErrorMapper {
static func userFriendlyMessage(for error: Error) -> String? {
let nsError = error as NSError
// URL-Ladefehler
if nsError.domain == NSURLErrorDomain {
switch nsError.code {
case NSURLErrorNotConnectedToInternet:
return String(localized: "You are not connected to the Internet. Please check your connection.")
case NSURLErrorTimedOut:
return String(localized: "The request timed out. Please try again later.")
// Viele weitere Fälle...
}
}
// Dateisystem-Fehler
if nsError.domain == NSCocoaErrorDomain {
switch nsError.code {
case NSFileNoSuchFileError:
return String(localized: "The file could not be found.")
// Viele weitere Fälle...
}
}
// Weitere Domains und Fehlercodes...
return nil // Fallback auf Standard-Behandlung
}
}Aktuelle Abdeckung und Beispiele
ErrorKit enthält Zuordnungen für häufige Fehler in wichtigen Apple-Frameworks:
Foundation
Netzwerk:
NSURLErrorNotConnectedToInternet→ “Your device isn’t connected to the internet. Please check your connection and try again.”Dateisystem:
NSFileNoSuchFileError→ “The file ‘report.pdf’ could not be found. Please verify the file name and location.”
Core Data
Validierung:
NSValidationErrorMinimum→ “The database failed validation. Please check your inputs and try again.”Store-Verwaltung:
NSPersistentStoreCoordinatorError→ “Database error. This might be due to a recent app update or file corruption.”
MapKit
Wegbeschreibungen:
MKErrorDirectionsNotFound→ “No directions found for the requested route.”Standort:
MKErrorLocationUnknown→ “Current location unavailable. Please check location permissions.”
Warum wir eine gemeinschaftliche Antwort brauchen
In einer idealen Welt würde Apple all seine verwirrenden Fehlermeldungen fixen. Und fairerweise muss man sagen: Sie haben einiges verbessert – neuere Frameworks wie SwiftUI sind deutlich klarer. Aber Jahrzehnte von Legacy-APIs liefern eben immer noch kryptische, technische Meldungen, die wohl nie wieder angefasst werden.
Genau hier kann unsere Community einen echten Unterschied machen. Kein einzelner Entwickler hat jeden obskuren Fehler gesehen – aber zusammen haben wir die meisten davon erlebt. Indem wir teilen, was wir bereits herausgefunden haben, und diese Meldungen in verständliche Sprache umschreiben, können wir eine Ressource schaffen, die allen Zeit spart und die Erfahrung für Entwickler und Nutzer gleichermaßen verbessert.
So kannst du beitragen
Wenn du schon mal eine System-Fehlermeldung umgeschrieben hast, um sie hilfreicher zu machen, machst du die Arbeit ja bereits – jetzt kannst du sie teilen. Hier sind die 3 grundlegenden Schritte:
Eine schlechte Meldung entdecken Notiere die Error-Domain und den Code, die Operation, die den Fehler ausgelöst hat, sowie nützliche Infos aus dem
userInfo-Dictionary.Eine bessere Version schreiben Verwende verständliche Sprache. Sei konkret. Biete einen hilfreichen nächsten Schritt an, wenn es Sinn ergibt.
Auf GitHub einreichen Eröffne einen Pull Request oder ein Issue im ErrorKit-Repo mit deiner verbesserten Meldung, dem ursprünglichen Kontext und eventuellen Anmerkungen.
Selbst kleine Beiträge können tausenden Entwicklern helfen und die Nutzererfahrung für Millionen verbessern!
Über Apple-Frameworks hinaus: Fehler beliebiger Libraries mappen
Während Apple-Frameworks der Hauptfokus sind, funktioniert ErrorKits Fehlerzuordnungssystem mit jedem Fehlertyp. Das ErrorMapper-Protocol ermöglicht es Entwicklern, eigene Zuordnungen für Third-Party-Libraries zu erstellen:
// Beispiel-Mapper für Alamofire-Netzwerkfehler
enum AlamofireErrorMapper: ErrorMapper {
static func userFriendlyMessage(for error: Error) -> String? {
switch error {
case let afError as Alamofire.AFError:
switch afError {
case .sessionTaskFailed(let underlying):
if let urlError = underlying as? URLError {
switch urlError.code {
case .notConnectedToInternet:
return String(localized: "Your device isn't connected to the internet. Please check your connection and try again.")
case .timedOut:
return String(localized: "The server took too long to respond. Please try again later.")
default:
return nil
}
}
return nil
case .responseValidationFailed(let reason):
if case .unacceptableStatusCode(let code) = reason {
return String(localized: "The server returned error \(code). Please check your request or try again later.")
}
return nil
default:
return nil
}
default:
return nil
}
}
}
// Für sofortige Verwendung registrieren
ErrorKit.registerMapper(AlamofireErrorMapper.self)Diese Erweiterbarkeit eröffnet Möglichkeiten für:
Eigene Zuordnungen in deiner App für beliebte Libraries wie Alamofire
Mapper-Packages für Closed-Source-SDKs wie Stripe, Admob usw.
Teilen von Fehlerzuordnungen innerhalb von Teams oder Organisationen
Fazit
Fehlermeldungen haben einen erheblichen Einfluss auf die Nutzererfahrung, werden in der Entwicklung aber oft übersehen. ErrorKits userFriendlyMessage(for:)-Funktion schafft einen Rahmen, um das durch Community-Zusammenarbeit zu ändern – eine Zusammenarbeit, bei der Entwickler ihr Wissen bündeln, um das gesamte Swift-Ökosystem benutzerfreundlicher zu machen.
Wenn du schon mal kryptische Fehlermeldungen entschlüsselt hast, ist deine Erfahrung wertvoll. Indem du zu ErrorKit beiträgst, kannst du diese Probleme nicht nur für dich selbst lösen, sondern für jeden Swift-Entwickler, der vor denselben Herausforderungen steht. Schau dir ErrorKit an und teile deine Lösungen, um diese Community-Ressource aufzubauen:
Seid ihr schon auf kryptische Fehlermeldungen in Apple-Frameworks gestoßen? Habt ihr sie für euch hilfreicher gemacht? Schreibt mir auf den sozialen Kanälen (Links unten)!