El mensaje de error se explica por sí mismo. El tiempo de ejecución esperaba no encontrar nil mientras desenvolvía una variable opcional que creaste, pero encontró uno allí, invalidando así todo el código que viene después de esa línea, por lo tanto la aplicación se estrelló.
En forma aún más larga: Hiciste una promesa al compilador y luego la rompiste. Le dijiste al compilador que estabas seguro de que tu variable no sería nula en el momento de acceder a ella, y luego el compilador demostró que eras un gran mentiroso. Hiciste esta promesa utilizando el operador «bang», que se parece a esto:
El operador bang se utiliza para denotar un opcional explícitamente desenvuelto, o un opcional forzado. Es decir, es una variable de tipo opcional (es decir, puede o no ser nil) para la que usted, como programador, está haciendo una promesa al compilador de que no será nil en el momento en que se accede a ella.
Esto ocurre en el momento de la declaración de la variable, así:
- var miInt: ¡Int!
o en el momento del acceso, así:
- var miInt: Int?
- dejar que miCadenaNecesaria = «¡(miIntNecesaria!)»
En este último caso, es menos como romper una promesa y más como decir en el último momento: «¡Confía en mí! ¡Sé que está ahí! Te mentiría?»
Este error sólo se encuentra cuando a alguien le pareció que usar if let o guard let era una enorme molestia o una atroz pérdida de tiempo. En lugar de utilizar una construcción sencilla que hiciera su código seguro, optaron por asumir que su cerebro humano normal podría pensar fácilmente en todos los posibles escenarios y momentos en los que se podría acceder a la variable. The solution: trust the tools of the language and write safe code rather than writing less code.
In both examples above, simply architecting the file so that the method accessing the optional could either exit early (if it’s a method that returns Void):
- var myNecessaryInt: Int?
- func doSomeStuffWithMyInt() {
- guard let necessaryInt = myNecessaryInt else {
- return
- }
- let theStringVersion = “(necessaryInt)”
- // and so on…
or that throws an error in the case that the variable is nil:
- var myNecessaryInt: Int?
- func doSomeStuffWithMyInt() throws {
- guard let necessaryInt = myNecessaryInt else {
- throw NSError(domain: «com.myApp»,
- code: 0,
- userInfo: [«description»: «The number wasn’t there.»])
- }
- let theStringVersion = “(necessaryInt)”
- // and so on…
Independientemente de cómo lo manejes, si estás escribiendo un código Swift estable y seguro, entonces el 99,999% de las veces evitarás usar !
En cuanto a por qué está fallando en ese error con SwiftUI, lo único que se me ocurre es que se está usando un opcional explícitamente desenvuelto en alguna parte de tu archivo SwiftUI. ¿Quizás el objeto modelo que lo respalda es un opcional desenvuelto a la fuerza, o se está introduciendo uno en la variable de estado que está vinculada a la vista? De cualquier manera, cuando el error se lanza, debe capturar el nombre del archivo y el número de línea, y si se agrega un punto de interrupción de la excepción en Xcode, incluso debe detenerse en esa línea y le permiten inspeccionar las variables disponibles en el ámbito de la línea infractora.