/* Page prose (fr) */
"ErrorsAsyncThrowsAndTryAwait" = "# Les erreurs: `async throws` et `try await`\n\nTu te souviens à quel point les erreurs étaient pénibles dans le code à callbacks (dans le chapitre [Pourquoi la concurrence moderne](Why%20Modern%20Concurrency.playgroundchapter/Overview))? Tu ne pouvais pas faire `throw` (la fonction avait déjà retourné) donc tu faisais passer un `Result` ou un paramètre `Error?` supplémentaire à travers chaque closure, en espérant qu'aucun chemin de code n'oublie d'appeler le completion handler.\n\nLes fonctions asynchrones lancent des erreurs de la façon *normale*. Marque la fonction `async throws`, appelle-la avec `try await`, et enveloppe-la dans un `do-try-catch` ordinaire:";
"ErrorsAsyncThrowsAndTryAwait-2" = "Lis ça de haut en bas: moudre, afficher, moudre, afficher (avec un seul `do-try-catch` autour de l'ensemble). Pas de closures imbriquées, pas de `Result`, pas de callbacks oubliés. Une erreur lancée au plus profond d'un appel asynchrone se propage jusqu'à ton `catch` exactement comme un throw synchrone.\n\n**Observe l'exécution:** tu verras `Ground 18 g of beans`, puis environ une demi-seconde plus tard `⚠️ Refill the hopper and try again`. Le second `print` ne s'exécute jamais, parce que `try await grind(grams: 0)` a lancé une erreur et a sauté directement au `catch` correspondant.\n\n> **Ordre de `try await`:** écris `try` d'abord, puis `await` (`try await grind(...)`). Pense \"essaie d'attendre ceci (try to await this).\"\n\n[Précédent](@previous)  |  page 6 sur 8  |  [Suivant: Exécuter du travail de façon concurrente avec async let](@next)";
