<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Why I Don&#8217;t Use Async Await	</title>
	<atom:link href="https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/feed" rel="self" type="application/rss+xml" />
	<link>https://jessewarden.com/2021/06/why-i-dont-use-async-await.html</link>
	<description>Software &#124; Fitness &#124; Gaming</description>
	<lastBuildDate>Tue, 13 Jul 2021 06:30:30 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: richard devis		</title>
		<link>https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/comment-page-1#comment-256330</link>

		<dc:creator><![CDATA[richard devis]]></dc:creator>
		<pubDate>Tue, 13 Jul 2021 06:30:30 +0000</pubDate>
		<guid isPermaLink="false">https://jessewarden.com/?p=6250#comment-256330</guid>

					<description><![CDATA[Thanks for sharing this, It is really helpful.]]></description>
			<content:encoded><![CDATA[<p>Thanks for sharing this, It is really helpful.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: JesterXL		</title>
		<link>https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/comment-page-1#comment-256235</link>

		<dc:creator><![CDATA[JesterXL]]></dc:creator>
		<pubDate>Mon, 05 Jul 2021 16:39:37 +0000</pubDate>
		<guid isPermaLink="false">https://jessewarden.com/?p=6250#comment-256235</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/comment-page-1#comment-256036&quot;&gt;gotofritz&lt;/a&gt;.

Apologies about the formatting, blogs are the worst at that.

The point isn&#039;t about &quot;where it came from&quot;. I get with try/catch it&#039;s &quot;it&#039;s this try/catch block _here_ that is the problem&quot;. That&#039;s a start, sure, but generally at runtime, none of it matters. What you should be doing is:

Step 1: promise chain to catch all or try/catch all.
Step 2: return errors from functions vs. raising &amp; explaining them vs. &quot;where did things go wrong&quot;. Like Go/Lua.
Step 3: If more than 1 possible failure, return union type / discriminated union.
Step 4: If you continue to use JavaScript without types, still keep 1 single catch or try/catch.

Step 2 and 3 aren&#039;t what people usually think about. In JavaScript, the attitude typically is &quot;anything can fail, keep running as fast as possible the code over and over until we figure out all possible errors&quot;. Instead, if you focus on an individual function&#039;s ability to either work or not. Pure functions like &quot;getting todays date&quot;, you&#039;re ok, but things like &quot;make an HTTP call&quot; are insanely complex. At first, you can only return 2 things; it worked, or didn&#039;t. Later, once you learn the HTTP status codes, what their values mean with the API you&#039;re interacting with, and the response JSON/XML/HTML/whatever format, you can further add more helpful return values or error values.

In short, don&#039;t use throw, don&#039;t use catch. Make all functions pure, and only return errors at first that verbose. Later, you can return multiple types of errors, and either chain them using Promises (since catch is built-in) or their native bind functionality.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/comment-page-1#comment-256036">gotofritz</a>.</p>
<p>Apologies about the formatting, blogs are the worst at that.</p>
<p>The point isn&#8217;t about &#8220;where it came from&#8221;. I get with try/catch it&#8217;s &#8220;it&#8217;s this try/catch block _here_ that is the problem&#8221;. That&#8217;s a start, sure, but generally at runtime, none of it matters. What you should be doing is:</p>
<p>Step 1: promise chain to catch all or try/catch all.<br />
Step 2: return errors from functions vs. raising &#038; explaining them vs. &#8220;where did things go wrong&#8221;. Like Go/Lua.<br />
Step 3: If more than 1 possible failure, return union type / discriminated union.<br />
Step 4: If you continue to use JavaScript without types, still keep 1 single catch or try/catch.</p>
<p>Step 2 and 3 aren&#8217;t what people usually think about. In JavaScript, the attitude typically is &#8220;anything can fail, keep running as fast as possible the code over and over until we figure out all possible errors&#8221;. Instead, if you focus on an individual function&#8217;s ability to either work or not. Pure functions like &#8220;getting todays date&#8221;, you&#8217;re ok, but things like &#8220;make an HTTP call&#8221; are insanely complex. At first, you can only return 2 things; it worked, or didn&#8217;t. Later, once you learn the HTTP status codes, what their values mean with the API you&#8217;re interacting with, and the response JSON/XML/HTML/whatever format, you can further add more helpful return values or error values.</p>
<p>In short, don&#8217;t use throw, don&#8217;t use catch. Make all functions pure, and only return errors at first that verbose. Later, you can return multiple types of errors, and either chain them using Promises (since catch is built-in) or their native bind functionality.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: gotofritz		</title>
		<link>https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/comment-page-1#comment-256037</link>

		<dc:creator><![CDATA[gotofritz]]></dc:creator>
		<pubDate>Fri, 25 Jun 2021 16:17:51 +0000</pubDate>
		<guid isPermaLink="false">https://jessewarden.com/?p=6250#comment-256037</guid>

					<description><![CDATA[Gosh, unformatted comments [rolls eyes] ... why even bother]]></description>
			<content:encoded><![CDATA[<p>Gosh, unformatted comments [rolls eyes] &#8230; why even bother</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: gotofritz		</title>
		<link>https://jessewarden.com/2021/06/why-i-dont-use-async-await.html/comment-page-1#comment-256036</link>

		<dc:creator><![CDATA[gotofritz]]></dc:creator>
		<pubDate>Fri, 25 Jun 2021 16:17:07 +0000</pubDate>
		<guid isPermaLink="false">https://jessewarden.com/?p=6250#comment-256036</guid>

					<description><![CDATA[Strange, the single catch at the end of a promise chain you consider a plus point, even though it&#039;s virtually impossible to debug where it came from. Whereas the single try/catch clause you consider a minus point. IT&#039;S EXACTLY THE SAME THING.

You can have interleave different then/catches exactly as you can interleave different try/catches. 

&lt;code&gt;
someFn()
  .then(anotherFn)
  .catch(thatFn)
  .then(anotherFn)
  .then(anotherFn)
  .catch(thatFn)

async wrapper() =&#062; {
  try {
   await someFn();
} catch(e) {
  thatFn()
}
try {
  ... 
 etc
&lt;/code&gt;

I really see no difference, except that you can debug the async/await much more easily.

Another thing that you can do, of course, is to create different types of errors, and catch them all at the end

&lt;code&gt;
try {
   await someFn()
   if (something) {
      throw ErrorX()
   }
   await anotherFn() &#124;&#124; throw ErrorY();
  ...
}
catch (e) {
   if (e instaceof ErrorX) 
   ...
&lt;/code&gt;]]></description>
			<content:encoded><![CDATA[<p>Strange, the single catch at the end of a promise chain you consider a plus point, even though it&#8217;s virtually impossible to debug where it came from. Whereas the single try/catch clause you consider a minus point. IT&#8217;S EXACTLY THE SAME THING.</p>
<p>You can have interleave different then/catches exactly as you can interleave different try/catches. </p>
<p><code><br />
someFn()<br />
  .then(anotherFn)<br />
  .catch(thatFn)<br />
  .then(anotherFn)<br />
  .then(anotherFn)<br />
  .catch(thatFn)</p>
<p>async wrapper() =&gt; {<br />
  try {<br />
   await someFn();<br />
} catch(e) {<br />
  thatFn()<br />
}<br />
try {<br />
  ...<br />
 etc<br />
</code></p>
<p>I really see no difference, except that you can debug the async/await much more easily.</p>
<p>Another thing that you can do, of course, is to create different types of errors, and catch them all at the end</p>
<p><code><br />
try {<br />
   await someFn()<br />
   if (something) {<br />
      throw ErrorX()<br />
   }<br />
   await anotherFn() || throw ErrorY();<br />
  ...<br />
}<br />
catch (e) {<br />
   if (e instaceof ErrorX)<br />
   ...<br />
</code></p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
