<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Exceptions on PG Blog</title><link>https://pg-blogs.netlify.app/tags/exceptions/</link><description>Recent content in Exceptions on PG Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 03 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pg-blogs.netlify.app/tags/exceptions/index.xml" rel="self" type="application/rss+xml"/><item><title>Error Handling Best Practices in Java</title><link>https://pg-blogs.netlify.app/posts/4-error-handling-best-practices-in-java/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/4-error-handling-best-practices-in-java/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Error handling is where a lot of otherwise-good Java code quietly goes wrong. Exceptions get swallowed, &lt;code&gt;null&lt;/code&gt; leaks across boundaries, and stack traces arrive with no context about &lt;em&gt;what the program was trying to do&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;Good error handling is not about catching everything. It is about being deliberate: fail fast on programmer errors, recover gracefully from expected failures, and never lose the information a future on-call engineer will need.&lt;/p&gt;</description></item><item><title>Error Handling Best Practices in Python</title><link>https://pg-blogs.netlify.app/posts/5-error-handling-best-practices-in-python/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/5-error-handling-best-practices-in-python/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Python&amp;rsquo;s error handling reads deceptively simply — &lt;code&gt;try&lt;/code&gt;, &lt;code&gt;except&lt;/code&gt;, done. But the difference between code that fails clearly and code that fails mysteriously comes down to a handful of habits: catching the &lt;em&gt;right&lt;/em&gt; exception, preserving the original cause, and knowing when &lt;em&gt;not&lt;/em&gt; to raise at all.&lt;/p&gt;
&lt;p&gt;This post covers the practices that keep Python failures debuggable in production.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="prefer-eafp-over-look-before-you-leap"&gt;Prefer EAFP over Look-Before-You-Leap&lt;/h2&gt;
&lt;p&gt;Python idiom favors &lt;strong&gt;EAFP&lt;/strong&gt; — &amp;ldquo;Easier to Ask Forgiveness than Permission.&amp;rdquo; Rather than checking whether an operation will succeed, attempt it and handle the failure:&lt;/p&gt;</description></item></channel></rss>