<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>Seenso</author><text>&amp;gt; A record not being found is a normal thing!&lt;p&gt;It&amp;#x27;s &lt;i&gt;not&lt;/i&gt; a normal thing for code that needs that record that wasn&amp;#x27;t found.&lt;p&gt;&amp;gt; They literally tell you nothing and there&amp;#x27;s no way to solve them without catching&amp;#x2F;rescuing them. A null value, a plain &amp;quot;error&amp;quot; object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I&amp;#x27;ll do it myself.&lt;p&gt;They tell you lots: you asked for something your code path wanted and your request couldn&amp;#x27;t be satisfied.  Also, you&amp;#x27;ve been helpfully kicked onto the alternative execution path to handle that situation.&lt;p&gt;Exceptions are a hell of a lot better than littering your code with null checks or error code checks, especially when you forget one and get a null pointer error or your code wanders away from the root cause and fails later.</text></item><item><author>ravenstine</author><text>My problem with exceptions isn&amp;#x27;t so much exceptions themselves but the way they&amp;#x27;re used.&lt;p&gt;The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function).  In other words, I don&amp;#x27;t think it&amp;#x27;s that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid.  If you aren&amp;#x27;t using types, raising an exception can be helpful to provide feedback and useful information when data isn&amp;#x27;t formatted correctly.&lt;p&gt;Exceptions suck when they&amp;#x27;re used for problems that aren&amp;#x27;t actual problems.  For example, if a query is made to an API for a record and that record isn&amp;#x27;t found, the SDK wrapping that API would raise a &amp;quot;Record not found&amp;quot; exception.  What the hell?  A record not being found is a &lt;i&gt;normal&lt;/i&gt; thing!  I&amp;#x27;ve seen this kind of thing all over the place, and I recently had to write some application code to work around one of these useless exceptions.  They literally tell you nothing and there&amp;#x27;s no way to solve them without catching&amp;#x2F;rescuing them.  A null value, a plain &amp;quot;error&amp;quot; object, or an error argument in a callback would have been sufficient.  If I need an exception to be raised for this kind of thing, I&amp;#x27;ll do it myself.</text></item></parent_chain><comment><author>ravenstine</author><text>&amp;gt; It&amp;#x27;s not a normal thing for code that needs that record that wasn&amp;#x27;t found.&lt;p&gt;No offense, but I don&amp;#x27;t know where that idea comes from.  Systems are checking for records &lt;i&gt;all the time&lt;/i&gt; in ways where the absence of data doesn&amp;#x27;t necessitate throwing an exception.&lt;p&gt;For instance, a page, user, or piece of media on a website may have existed at one point but was since deleted, but still has a permalink floating around the net.  Is it useful, in the case that someone clicks on such a link, to throw an exception when I can instead choose to render different page content when a record wasn&amp;#x27;t found?  I&amp;#x27;ll never need a stack trace for that.&lt;p&gt;&amp;gt; They tell you lots: you asked for something your code path wanted and your request couldn&amp;#x27;t be satisfied. Also, you&amp;#x27;ve been helpfully kicked onto the alternative execution path to handle that situation.&lt;p&gt;Why would I want a code path for expected behavior?  I agree for cases like a failed connection, where the system is actually broken, but there isn&amp;#x27;t anything fundamentally broken about data absence.&lt;p&gt;&amp;gt; Also, you&amp;#x27;ve been helpfully kicked onto the alternative execution path to handle that situation.&lt;p&gt;That&amp;#x27;s not only presumptuous, but if I wanted that to happen, I can do so myself.&lt;p&gt;&amp;gt; Exceptions are a hell of a lot better than littering your code with null checks or error code checks, especially when you forget one and get a null pointer error.&lt;p&gt;Hmmm...&lt;p&gt;&lt;pre&gt;&lt;code&gt;  const record = store.findRecord(params.id);
  
  if (record) {
    render(&amp;#x27;show-record&amp;#x27;);
  } else {
    render(&amp;#x27;record-not-found&amp;#x27;);
  }

&lt;/code&gt;&lt;/pre&gt;
or...&lt;p&gt;&lt;pre&gt;&lt;code&gt;  try {
    const record = store.findRecord(params.id);
    render(&amp;#x27;show-record&amp;#x27;);
  } catch(err) {
    if (err.name === &amp;#x27;RECORD_NOT_FOUND&amp;#x27;) {
      render(&amp;#x27;record-not-found&amp;#x27;);
    } else {
      throw err;
    }
  }
&lt;/code&gt;&lt;/pre&gt;
I&amp;#x27;ll let people decide which one is better.  I personally prefer the first one.</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>Seenso</author><text>&amp;gt; A record not being found is a normal thing!&lt;p&gt;It&amp;#x27;s &lt;i&gt;not&lt;/i&gt; a normal thing for code that needs that record that wasn&amp;#x27;t found.&lt;p&gt;&amp;gt; They literally tell you nothing and there&amp;#x27;s no way to solve them without catching&amp;#x2F;rescuing them. A null value, a plain &amp;quot;error&amp;quot; object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I&amp;#x27;ll do it myself.&lt;p&gt;They tell you lots: you asked for something your code path wanted and your request couldn&amp;#x27;t be satisfied.  Also, you&amp;#x27;ve been helpfully kicked onto the alternative execution path to handle that situation.&lt;p&gt;Exceptions are a hell of a lot better than littering your code with null checks or error code checks, especially when you forget one and get a null pointer error or your code wanders away from the root cause and fails later.</text></item><item><author>ravenstine</author><text>My problem with exceptions isn&amp;#x27;t so much exceptions themselves but the way they&amp;#x27;re used.&lt;p&gt;The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function).  In other words, I don&amp;#x27;t think it&amp;#x27;s that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid.  If you aren&amp;#x27;t using types, raising an exception can be helpful to provide feedback and useful information when data isn&amp;#x27;t formatted correctly.&lt;p&gt;Exceptions suck when they&amp;#x27;re used for problems that aren&amp;#x27;t actual problems.  For example, if a query is made to an API for a record and that record isn&amp;#x27;t found, the SDK wrapping that API would raise a &amp;quot;Record not found&amp;quot; exception.  What the hell?  A record not being found is a &lt;i&gt;normal&lt;/i&gt; thing!  I&amp;#x27;ve seen this kind of thing all over the place, and I recently had to write some application code to work around one of these useless exceptions.  They literally tell you nothing and there&amp;#x27;s no way to solve them without catching&amp;#x2F;rescuing them.  A null value, a plain &amp;quot;error&amp;quot; object, or an error argument in a callback would have been sufficient.  If I need an exception to be raised for this kind of thing, I&amp;#x27;ll do it myself.</text></item></parent_chain><comment><author>kenoyer130</author><text>In Java&amp;#x2F;C# land exceptions are EXPENSIVE. Like magnatudes more expensive. You have to build a full stack trace etc. Removing places in the code where it is &amp;quot;Throwing exceptions for non exceptional circumstances&amp;quot; has a dramatic performance increase benefit.</text></comment>