/* Page prose (fr) */
"FailingWithAResult" = "# Quand le callback peut échouer: un `Result`\n\nLa plupart des vraies APIs de callback peuvent aussi *échouer*. Pour celles-là tu recours à **`withCheckedThrowingContinuation`**, la sœur qui lance: sa continuation peut reprendre en *lançant* aussi bien qu'en retournant, donc un callback échoué fait lancer l'appel qui attend.\n\nLes vieilles APIs de callback signalent l'échec sous deux formes classiques. Tu feras le pont pour les deux, en commençant par un `Result`.\n\nSi le callback te remet un `Result<Success, Failure>`, il y a une seule ligne: `continuation.resume(with: result)`. Elle déballe le `Result` pour toi: en reprenant avec la valeur sur `.success`, en lançant sur `.failure`.";
"FailingWithAResult-2" = "**Observe l'exécution:** la première recherche se résout après une courte pause et imprime la note de dégustation. La seconde reprend en **lançant**, donc le contrôle saute au `catch` et imprime `Lookup failed: unknownItem(\"Mystery\")`. Du côté de l'appelant, ça se lit comme un `try await` ordinaire: le callback et le `Result` ont disparu.\n\n* callout(Essaie): Change la seconde recherche de `\"Mystery\"` à `\"Guji\"`. Maintenant les deux se résolvent en retournant, les deux notes de dégustation s'impriment, et le `catch` ne s'exécute jamais.\n\n[Précédent](@previous)  |  page 3 sur 8  |  [Suivant: Échouer avec une paire (valeur, erreur)](@next)";
