Une perspective d'ensemble à ajouter aux autres réponses utiles mais plus centrées sur les détails:
Dans Swift, le point d'exclamation apparaît dans plusieurs contextes:
- Déballage forcé:
let name = nameLabel!.text
- Options optionnelles implicitement déballées:
var logo: UIImageView!
- Coulée forcée:
logo.image = thing as! UIImage
- Exceptions non gérées:
try! NSJSONSerialization.JSONObjectWithData(data, [])
Chacun d'eux est une construction de langage différente avec une signification différente, mais ils ont tous trois points importants en commun:
1. Les points d'exclamation contournent les contrôles de sécurité de Swift au moment de la compilation.
Lorsque vous utilisez !
dans Swift, vous dites essentiellement: «Hé, compilateur, je sais que vous pensez qu'une erreur pourrait se produire ici, mais je sais avec une certitude absolue que cela ne se produira jamais."
Tout le code valide ne rentre pas dans la boîte du système de type de compilation de Swift - ou dans la vérification de type statique d' une langue, d'ailleurs. Il existe des situations où vous pouvez prouver logiquement qu'une erreur ne se produira jamais, mais vous ne pouvez pas le prouver au compilateur . C'est pourquoi les concepteurs de Swift ont ajouté ces fonctionnalités en premier lieu.
Cependant, chaque fois que vous utilisez !
, vous excluez d'avoir un chemin de récupération pour une erreur, ce qui signifie que…
2. Les points d'exclamation sont des plantages potentiels.
Un point d'exclamation dit également: "Hé Swift, je suis si certain que cette erreur ne peut jamais se produire qu'il vaut mieux que vous plantiez toute mon application que pour moi de coder un chemin de récupération pour elle."
C'est une affirmation dangereuse. Il peut être le bon: dans le code critique où vous avez bien réfléchi aux invariants de votre code, il se peut que la sortie fausse soit pire qu'un crash.
Cependant, quand je vois !
à l'état sauvage, il est rarement utilisé avec autant de conscience. Au lieu de cela, cela signifie trop souvent: «cette valeur était facultative et je n'ai pas vraiment réfléchi à la raison pour laquelle elle pourrait être nulle ou à la façon de gérer correctement cette situation, mais en ajoutant!
fait compiler ... donc mon code est correct, non?"
Attention à l'arrogance du point d'exclamation. Au lieu…
3. Les points d'exclamation sont mieux utilisés avec parcimonie.
Chacune de ces !
constructions a une ?
contrepartie qui vous oblige à faire face au cas d'erreur / nul:
- Déballage conditionnel:
if let name = nameLabel?.text { ... }
- Optionnels:
var logo: UIImageView?
- Moulages conditionnels:
logo.image = thing as? UIImage
- Exceptions de zéro en cas d'échec:
try? NSJSONSerialization.JSONObjectWithData(data, [])
Si vous êtes tenté d'utiliser !
, il est toujours bon de considérer attentivement pourquoi vous n'utilisez pas à la ?
place. Est-ce que planter votre programme est vraiment la meilleure option si l' !
opération échoue? Pourquoi cette valeur est-elle facultative / disponible?
Existe-t-il un chemin de récupération raisonnable que votre code pourrait emprunter dans le cas nil / erreur? Si oui, codez-le.
Si cela ne peut pas être nul, si l'erreur ne peut jamais se produire, alors existe-t-il un moyen raisonnable de retravailler votre logique pour que le compilateur le sache? Si oui, faites-le; votre code sera moins sujet aux erreurs.
Il y a des moments où il n'y a aucun moyen raisonnable de gérer une erreur, et simplement ignorer l'erreur - et donc procéder avec des données erronées - serait pire que de planter. Ceux le moment d'utiliser le déballage forcé.
Je recherche périodiquement l'ensemble de ma base de code !
et vérifie chaque utilisation de celui-ci. Très peu d'utilisations résistent à l'examen. (Au moment de la rédaction de ce document, l'ensemble du framework Siesta en avait exactement deux instances .)
Cela ne veut pas dire que vous ne devriez jamais utiliser !
dans votre code - juste que vous devez l'utiliser en pleine conscience et ne jamais en faire l'option par défaut.