English is currently available.
Swift DISCUSSION
My app reads lines such as TEMP:23 from a serial-to-Bluetooth module and converts the number with Int(parts[1])!. It ran for hours and then crashed with "Unexpectedly found nil while unwrapping an Optional value". The line that caused it looked normal in the log.
I understand that ! is the problem, but what should replace it? There seem to be many options: if let, guard let, ??, ?.. When is each the right tool?
An Int? is a value that is either an Int or nil, and Int(someString) returns nil whenever the text is not a clean integer. The ! operator says "I guarantee this is not nil; crash if I am wrong". With external input you cannot give that guarantee.
The invisible culprit is usually whitespace: Int("23") is 23, but Int("23\r"), Int(" 23") and Int("23.0") are all nil. A line ending of \r\n split on \n leaves the carriage return attached, and it does not show in a log. Trim the field first with trimmingCharacters(in: .whitespacesAndNewlines) from Foundation.
guard let suits parsing code because it handles the failure first and leaves the unwrapped value available for the rest of the function: guard parts.count == 2, let value = Int(parts[1]) else { log(line); return }. After that line, value is a plain Int.
Note the parts.count check. Array subscripts are not optional in Swift: parts[1] on a one-element array is an immediate out-of-range crash, a separate failure from the nil unwrap and just as likely with a truncated line.
The others in short. if let value = Int(field) { ... } runs a block only when there is a value, which is good when the nil case needs no action. Int(field) ?? 0 substitutes a default; use it only when a default is really correct, since silently turning a corrupt reading into 0 can be worse than dropping it. Optional chaining, device?.name?.count, returns nil as soon as any link is nil and makes the whole expression optional.
map also works on optionals: Int(field).map { Double($0) * 0.1 } gives a Double? without any unwrapping syntax.
The same crash has less obvious sources: implicitly unwrapped declarations such as var label: UILabel! (an outlet that was never connected), as! casts, and try!. Each is a hidden force unwrap. Searching the project for ! after identifiers and for as! is a quick audit.
A force unwrap is reasonable only when nil means a bug in the program itself and not bad data, for example loading a resource that is compiled into the app. For everything that comes from a user, a file or a radio link, unwrap conditionally and decide what the failure path does.
Back to Swift community
