<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Functional Programming on mhbxyz.me</title><link>https://mhbxyz.github.io/en/tags/functional-programming/</link><description>Recent content in Functional Programming on mhbxyz.me</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 06 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://mhbxyz.github.io/en/tags/functional-programming/index.xml" rel="self" type="application/rss+xml"/><item><title>fptk: make errors explicit in a Python API</title><link>https://mhbxyz.github.io/en/articles/fptk-make-errors-explicit-in-a-python-api/</link><pubDate>Fri, 06 Feb 2026 00:00:00 +0000</pubDate><guid>https://mhbxyz.github.io/en/articles/fptk-make-errors-explicit-in-a-python-api/</guid><description>&lt;h2 id="the-problem-is-not-exceptions"&gt;The problem is not exceptions&lt;/h2&gt;
&lt;p&gt;An API request goes through several steps: decode JSON, validate input, write to a database, then build a response. Each step can fail. In Python, we can let exceptions rise and catch them at the end. That works, but a function&amp;rsquo;s signature does not tell us which operations can produce an expected failure. We may end up with one large &lt;code&gt;try/except&lt;/code&gt; around the whole request, without a clear idea of what it catches.&lt;/p&gt;</description></item></channel></rss>