/* Page prose (es) */
"ClassicModelTaxes" = "# El modelo clásico, y los impuestos que cobra\n\nTodo en el modelo clásico compartía una forma: iniciabas algún trabajo, le entregabas una **clausura** (un completion handler) para ejecutarse *más tarde*, y seguías adelante. Esa clausura es la costura donde el modelo clásico te factura en silencio. Cinco cargos aparecen una y otra vez:\n\n* **Completion handlers por todas partes.**  \nCada paso asíncrono termina llamando a *tu* clausura. Nada se ejecuta después de una llamada asíncrona como lo haría una línea normal; todo tiene que vivir *dentro* del handler.\n* **La pirámide de la perdición.**  \nCuando el paso B necesita el resultado del paso A, la llamada de B va dentro del handler de A. Añade el paso C y anidas de nuevo. El código marcha hacia la derecha.\n* **Errores que no pueden usar `throws`.**  \nUn completion handler no es una función de la que hagas `return`, así que no puedes hacer `throw`. Los errores viajan como valores que debes enrutar manualmente a cada quien los llama.\n* **Olvidar devolver la llamada.**  \nEn *algún* camino (un `return` temprano, una rama de error) es fácil olvidar llamar a la finalización. Quien llama entonces espera para siempre, sin ningún fallo que señale el error.\n* **Olvidar el salto al hilo principal.**  \nLos resultados llegan en una cola en segundo plano. Toca la UI desde ahí y tienes un error que solo *a veces* se muestra. Debes acordarte de saltar de vuelta al hilo principal a mano.\n\nConociste lo último de la contabilidad manual en el capítulo [Dependencias y cancelación de operaciones](Operation%20Dependencies%20and%20Cancellation.playgroundchapter/Overview): conectar dependencias entre operaciones, hilar una bandera de cancelación a través de cada una, comprobarla en los momentos adecuados. Poderoso, pero todo a tu cargo. Veamos cómo se acumulan estos impuestos en un pequeño trabajo.\n\n[Anterior](@previous)  |  página 2 de 6  |  [Siguiente: Un trabajo en tres pasos](@next)";
