<story><title>You’re better off using Exceptions</title><url>https://eiriktsarpalis.wordpress.com/2017/02/19/youre-better-off-using-exceptions/</url></story><parent_chain><item><author>abraxas</author><text>I don&amp;#x27;t know Rust at all but what you&amp;#x27;re talking about sounds  equivalent to (much maligned) Java&amp;#x27;s checked exceptions system?&lt;p&gt;I never understood the hatred checked exceptions received especially from the younger crowd. I still write Java at work and I still use checked exceptions whenever they indicate an error condition that must not be ignored by the client code. Many new to the project developers hate me for it initially because they can&amp;#x27;t just &amp;quot;roll out a feature&amp;quot; without being forced to take care of the corner cases but over time they love the discipline that&amp;#x27;s imposed on them by checked exceptions.</text></item><item><author>pat2man</author><text>When I moved to Rust the constant error wrapping or converting annoyed me. But after using it for a couple of years it turned out to be a huge blessing. Quite often I need to know exactly which error messages will be thrown so that I can do things like internationalization. While exceptions are quite convenient for prototyping for production I’m now firmly in the typed errors camp.</text></item></parent_chain><comment><author>oconnor663</author><text>I haven&amp;#x27;t written very much Java, but here are some differences between Java checked exceptions and Rust errors as I understand them:&lt;p&gt;In Java, a function may throw a long list of checked exceptions, and these lists tend to grow to inconvenient sizes in larger programs. For example, if foo() calls bar() and baz(), which each throw 3 different exception types, then now foo() might throw 6 different exception types. In contrast in Rust, each function can only return 1 error type. If a function needs to represent several different types of internal errors, then the crate that it&amp;#x27;s in needs to define an error enum type with a variant for each of those. (Either that, or the function can use a generic wrapper error that can contain anything. This is less common in library code but pretty common in application code.) This shifts a lot of work from library callers to library authors, which is a good thing.&lt;p&gt;Someone with more Java experience will need to correct me here: I think it&amp;#x27;s fairly common to bulldoze all that complexity by declaring a function that just &amp;quot;throws Exception&amp;quot;. That saves you from writing out N different types (and more importantly, from changing every transitive caller when a low level library introduces a new exception type). But it kind of defeats the purpose of checked exceptions, by throwing away all the info they provide. It&amp;#x27;s a shame that you have this &amp;quot;all or nothing&amp;quot; choice when it comes to exceptions and how much complexity you want to deal with. In contrast in Rust, wrapper errors can define automatic &amp;quot;From&amp;quot; conversions from the lower level error types they wrap, and the standard `?` operator automatically applies those conversions. That means that in many cases, a low level library adding a new error variant might not require any changes in its callers at all. The new information is there for callers who want to look for it, but existing abstractions around the error type generally just keep working.</text></comment>
<story><title>You’re better off using Exceptions</title><url>https://eiriktsarpalis.wordpress.com/2017/02/19/youre-better-off-using-exceptions/</url></story><parent_chain><item><author>abraxas</author><text>I don&amp;#x27;t know Rust at all but what you&amp;#x27;re talking about sounds  equivalent to (much maligned) Java&amp;#x27;s checked exceptions system?&lt;p&gt;I never understood the hatred checked exceptions received especially from the younger crowd. I still write Java at work and I still use checked exceptions whenever they indicate an error condition that must not be ignored by the client code. Many new to the project developers hate me for it initially because they can&amp;#x27;t just &amp;quot;roll out a feature&amp;quot; without being forced to take care of the corner cases but over time they love the discipline that&amp;#x27;s imposed on them by checked exceptions.</text></item><item><author>pat2man</author><text>When I moved to Rust the constant error wrapping or converting annoyed me. But after using it for a couple of years it turned out to be a huge blessing. Quite often I need to know exactly which error messages will be thrown so that I can do things like internationalization. While exceptions are quite convenient for prototyping for production I’m now firmly in the typed errors camp.</text></item></parent_chain><comment><author>hocuspocus</author><text>&amp;gt; I don&amp;#x27;t know Rust but it sounds like equivalent to much maligned Java&amp;#x27;s checked exceptions?&lt;p&gt;Ergonomics are important. Chaining calls to functions that return a monadic Result&amp;#x2F;Either type is easier and neater.</text></comment>