<story><title>Checked exceptions: Java’s biggest mistake (2014)</title><url>http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/</url></story><parent_chain><item><author>hota_mazi</author><text>Right.&lt;p&gt;They don&amp;#x27;t just &amp;quot;encourage&amp;quot; developers to consider error paths, they &amp;quot;force&amp;quot; them to do so.&lt;p&gt;The concept of checked exceptions is very sound, as is the more general concept of compiler enforced error checking. Very, very few languages have that (only Java and Kotlin in the mainstream league).&lt;p&gt;Languages with a solid implementation of algebraic data types offer a good first step in that direction but they still require users to manually bubble and compose monadic values, which introduces an unnecessary, and sometimes intractable, level of obfuscation and boiler plate.&lt;p&gt;All other languages provide weaker approaches to this concept that are library enforced, not language enforced, and therefore more prone to being overlooked since they require discipline from the developer.</text></item><item><author>alasdair_</author><text>I like checked exceptions. Yes, sometimes (especially in the oldest APIs when they were still figuring this stuff out), they were overused but mostly I think they encourage developers to really think about what happens in the failure case.&lt;p&gt;I notice this especially with less experienced developers and remote calls - a lot of JS code I’ve reviewed in the past assumes the remote call will always work, yet Java code from the &lt;i&gt;same&lt;/i&gt; developer will almost always correctly handle the situation, simply because the exception is explicitly required to be handled.</text></item></parent_chain><comment><author>dllthomas</author><text>I conjecture that much of the &lt;i&gt;legitimate&lt;/i&gt; pain from checked exceptions in Java were because the language to talk about exceptions was so limited.&lt;p&gt;For instance, consider fold or map functions.  There was no way of saying &amp;quot;this might throw anything that might throw&amp;quot;, so the only option was &amp;quot;this won&amp;#x27;t throw anything and &lt;i&gt;that cannot throw anything&lt;/i&gt;&amp;quot; or &amp;quot;this might throw anything&amp;quot;.&lt;p&gt;Without the necessary flexibility, developers aren&amp;#x27;t &amp;quot;forced&amp;quot; to consider only &lt;i&gt;error&lt;/i&gt; paths but also manifold &lt;i&gt;impossible&lt;/i&gt; paths that aren&amp;#x27;t easily distinguished from legitimate error paths.</text></comment>
<story><title>Checked exceptions: Java’s biggest mistake (2014)</title><url>http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/</url></story><parent_chain><item><author>hota_mazi</author><text>Right.&lt;p&gt;They don&amp;#x27;t just &amp;quot;encourage&amp;quot; developers to consider error paths, they &amp;quot;force&amp;quot; them to do so.&lt;p&gt;The concept of checked exceptions is very sound, as is the more general concept of compiler enforced error checking. Very, very few languages have that (only Java and Kotlin in the mainstream league).&lt;p&gt;Languages with a solid implementation of algebraic data types offer a good first step in that direction but they still require users to manually bubble and compose monadic values, which introduces an unnecessary, and sometimes intractable, level of obfuscation and boiler plate.&lt;p&gt;All other languages provide weaker approaches to this concept that are library enforced, not language enforced, and therefore more prone to being overlooked since they require discipline from the developer.</text></item><item><author>alasdair_</author><text>I like checked exceptions. Yes, sometimes (especially in the oldest APIs when they were still figuring this stuff out), they were overused but mostly I think they encourage developers to really think about what happens in the failure case.&lt;p&gt;I notice this especially with less experienced developers and remote calls - a lot of JS code I’ve reviewed in the past assumes the remote call will always work, yet Java code from the &lt;i&gt;same&lt;/i&gt; developer will almost always correctly handle the situation, simply because the exception is explicitly required to be handled.</text></item></parent_chain><comment><author>ragnese</author><text>Kotlin has no mechanism to force error handling. You may suggest that we use sealed classes as return values and match on them, which is okay-ish, but suffers from two big issues:&lt;p&gt;1. You are not forced to use the result, so if you call a function for its side effects, the compiler will not warn you that you should unwrap the value. Rust and Swift do not have this issue.&lt;p&gt;2. This is extremely tedious, as you mention. But it&amp;#x27;s specific to Kotlin and not generally true as you later suggest. Haskell had monad comprehension (do notation), Scala has the same thing, Rust has the ? operator.&lt;p&gt;Also, regarding Kotlin; no library, nor the standard library, does anything other than throw unchecked exceptions on all kinds of failures. Kotlin is a step backwards, IMO.&lt;p&gt;Also PHP has checked exceptions, like Java.</text></comment>