<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gestion Des Erreurs on mhbxyz.me</title><link>https://mhbxyz.github.io/fr/tags/gestion-des-erreurs/</link><description>Recent content in Gestion Des Erreurs on mhbxyz.me</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Fri, 06 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://mhbxyz.github.io/fr/tags/gestion-des-erreurs/index.xml" rel="self" type="application/rss+xml"/><item><title>fptk : rendre les erreurs explicites dans une API Python</title><link>https://mhbxyz.github.io/fr/articles/fptk-rendre-les-erreurs-explicites-dans-une-api-python/</link><pubDate>Fri, 06 Feb 2026 00:00:00 +0000</pubDate><guid>https://mhbxyz.github.io/fr/articles/fptk-rendre-les-erreurs-explicites-dans-une-api-python/</guid><description>&lt;h2 id="le-problème-nest-pas-lexception"&gt;Le problème n&amp;rsquo;est pas l&amp;rsquo;exception&lt;/h2&gt;
&lt;p&gt;Une requête d&amp;rsquo;API traverse plusieurs étapes : décoder le JSON, vérifier les données, écrire en base, puis construire la réponse. Chacune peut échouer. En Python, on peut laisser les exceptions remonter et les intercepter à la fin. Cela fonctionne, mais la signature des fonctions ne dit pas quelles étapes produisent un échec attendu. On finit parfois avec un &lt;code&gt;try/except&lt;/code&gt; qui entoure tout le traitement et ne sait plus très bien ce qu&amp;rsquo;il attrape.&lt;/p&gt;</description></item></channel></rss>