win10arcgisjavascript錯(cuò)誤

原因可能是：應(yīng)用程序發(fā)生異常未知的軟件異常

成都創(chuàng)新互聯(lián)公司是一家專(zhuān)注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃、微信小程序開(kāi)發(fā)、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動(dòng)互聯(lián)開(kāi)發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立十余年以來(lái)，已經(jīng)為近千家宣傳片制作各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)。現(xiàn)在，服務(wù)的近千家客戶(hù)與我們一路同行，見(jiàn)證我們的成長(zhǎng)；未來(lái)，我們一起分享成功的喜悅。

1.病毒木馬造成的，在當(dāng)今互聯(lián)網(wǎng)時(shí)代，病毒坐著為了獲得更多的牟利，常用病毒綁架應(yīng)用程序和系統(tǒng)文件，然后某些安全殺毒軟件把被病毒木馬感染的應(yīng)用程序和系統(tǒng)文件當(dāng)病毒殺了導(dǎo)致的。

2.應(yīng)用程序組件丟失，應(yīng)用程序完整的運(yùn)行需要一些系統(tǒng)文件或者某些ll文件支持的，如果應(yīng)用程序組件不完整也會(huì)導(dǎo)致的。

3.系統(tǒng)文件損壞或丟失，盜版系統(tǒng)或Ghost版本系統(tǒng)，很容易出現(xiàn)該問(wèn)題。

4.操作系統(tǒng)自身的問(wèn)題，操作系統(tǒng)本身也會(huì)有bug。

5.硬件問(wèn)題，例如內(nèi)存條壞了或者存在質(zhì)量問(wèn)題，或者內(nèi)存條的金手指的灰塵特別多。

小米攝像頭提示未處理的js異常怎么辦

1、首先測(cè)試一下硬件是否有問(wèn)題。

2、其次可以嘗試一下恢復(fù)出廠(chǎng)設(shè)置，如果沒(méi)問(wèn)題可以刷機(jī)解決。

3、如果有問(wèn)題就需要到售后聯(lián)系專(zhuān)業(yè)人員處理。

JS位運(yùn)算異常（位運(yùn)算精度丟失）的原因探究

《【轉(zhuǎn)+補(bǔ)充】深入研究js中的位運(yùn)算及用法》

《【JS時(shí)間戳】獲取時(shí)間戳的最快方式探究》

日常開(kāi)發(fā)中一直沒(méi)遇到過(guò)位運(yùn)算導(dǎo)致精度丟失的問(wèn)題，直到這天，搞10位時(shí)間戳取整的時(shí)候，終于被我撞上了。具體是個(gè)什么場(chǎng)景呢，我們來(lái)還原下案發(fā)現(xiàn)場(chǎng)：

可以看到輸出的結(jié)果為：

得到的 t 是一個(gè)精確到微秒的時(shí)間戳。但是請(qǐng)求接口的時(shí)候需要的是一個(gè)10位（精確到秒）的時(shí)間戳，所以這里需要將它轉(zhuǎn)換為10位，自然就是 ?1000 即可，然后通過(guò)位運(yùn)算來(lái)實(shí)現(xiàn)類(lèi)似 Math.trunc 的取證效果，得到了我們要的10位時(shí)間戳。至此完美解決！那問(wèn)題又是如何發(fā)生的呢？

按照上面的運(yùn)算規(guī)律，如果我們要獲取13位時(shí)間戳，是不是直接對(duì) t0 就可以了呢？我們來(lái)看一下：

輸出結(jié)果如下：

WTF!!!看到了咩！！！居然輸出了一個(gè)負(fù)數(shù)！！！我們想要的結(jié)果應(yīng)該是 1597113682985 才對(duì)啊！為什么會(huì)出現(xiàn)了負(fù)數(shù)呢！！！

由此，怪物出現(xiàn)啦！我們今天就來(lái)解讀（xiang fu)一下它！

想到這里，我們一定就會(huì)怪是位運(yùn)算的鍋！那這個(gè)鍋該怎么讓位運(yùn)算背起來(lái)呢！我們來(lái)研究一下！

首先我們知道，JS中沒(méi)有真正的整型，數(shù)據(jù)都是以double(64bit)的標(biāo)準(zhǔn)格式存儲(chǔ)的，這里就不再贅述了，要想搞透其中的原理，請(qǐng)打開(kāi) 【傳送門(mén)】

位運(yùn)算是在數(shù)字底層（即表示數(shù)字的 32 個(gè)數(shù)位）進(jìn)行運(yùn)算的。由于位運(yùn)算是低級(jí)的運(yùn)算操作，所以速度往往也是最快的（相對(duì)其它運(yùn)算如加減乘除來(lái)說(shuō)），并且借助位運(yùn)算有時(shí)我們還能實(shí)現(xiàn)更簡(jiǎn)單的程序邏輯,缺點(diǎn)是很不直觀(guān)，許多場(chǎng)合不能夠使用。

以下來(lái)源于w3shool:

ECMAScript 整數(shù)有兩種類(lèi)型，即有符號(hào)整數(shù)（允許用正數(shù)和負(fù)數(shù)）和無(wú)符號(hào)整數(shù)（只允許用正數(shù)）。 在 ECMAScript 中，所有整數(shù)字面量默認(rèn)都是有符號(hào)整數(shù) ，這意味著什么呢？

有符號(hào)整數(shù)使用 31 位表示整數(shù)的數(shù)值，用第 32 位表示整數(shù)的符號(hào)，0 表示正數(shù)，1 表示負(fù)數(shù)。數(shù)值范圍從 -2147483648 到 2147483647 。

可以以?xún)煞N不同的方式存儲(chǔ)二進(jìn)制形式的有符號(hào)整數(shù)，一種用于存儲(chǔ)正數(shù)，一種用于存儲(chǔ)負(fù)數(shù)。 正數(shù)是以真二進(jìn)制形式存儲(chǔ)的 ，前 31 位中的每一位都表示 2 的冪，從第 1 位（位 0）開(kāi)始，表示 20，第 2 位（位 1）表示 21。沒(méi)用到的位用 0 填充，即忽略不計(jì)。例如，下圖展示的是數(shù) 18 的表示法。

那在js中二進(jìn)制和十進(jìn)制如何轉(zhuǎn)換呢？如下

負(fù)數(shù)同樣以二進(jìn)制存儲(chǔ)，但使用的格式是二進(jìn)制補(bǔ)碼。計(jì)算一個(gè)數(shù)值的二進(jìn)制補(bǔ)碼，需要經(jīng)過(guò)下列3個(gè)步驟：

例如，要確定-18的二進(jìn)制表示，首先必須得到18的二進(jìn)制表示，如下所示：

0000 0000 0000 0000 0000 0000 0001 0010

接下來(lái)，計(jì)算二進(jìn)制反碼，如下所示：

1111 1111 1111 1111 1111 1111 1110 1101

最后，在二進(jìn)制反碼上加 1，如下所示：

1111 1111 1111 1111 1111 1111 1110 1101 +

0000000000000000000000000000 0001 =

1111 1111 1111 1111 1111 1111 1110 1110

因此，-18 的二進(jìn)制就是 1111 1111 1111 1111 1111 1111 1110 1110

而其相反數(shù)18的二進(jìn)制為 0000 0000 0000 0000 0000 0000 0001 0010

ECMAScript會(huì)盡力向我們隱藏所有這些信息，在以二進(jìn)制字符串形式輸出一個(gè)負(fù)數(shù)時(shí)，我們看到的只是這個(gè)負(fù)數(shù)絕對(duì)值的二進(jìn)制碼前面加上了一個(gè)負(fù)號(hào)

JavaScript 只有一種數(shù)字類(lèi)型 ( Number )

我們將 1596596596.3742654.toString(2) 轉(zhuǎn)為二進(jìn)制字符串表示如下：

1011111001010100010000101110100.0101111111001111110111

但實(shí)際在內(nèi)存中的存儲(chǔ)如下：

說(shuō)到這里就不得不簡(jiǎn)單提一下數(shù)字精度丟失的問(wèn)題。上面也知道，JS中所有的數(shù)字都是用double方式進(jìn)行存儲(chǔ)的，所以必然會(huì)存在精度丟失問(wèn)題。

以下轉(zhuǎn)自文章： JavaScript數(shù)字精度丟失問(wèn)題總結(jié)

此時(shí)只能模仿十進(jìn)制進(jìn)行四舍五入了，但是二進(jìn)制只有 0 和 1 兩個(gè)，于是變?yōu)?0 舍 1 入。這即是計(jì)算機(jī)中部分浮點(diǎn)數(shù)運(yùn)算時(shí)出現(xiàn)誤差，丟失精度的根本原因。

大整數(shù)的精度丟失和浮點(diǎn)數(shù)本質(zhì)上是一樣的，尾數(shù)位最大是 52 位，因此 JS 中能精準(zhǔn)表示的最大整數(shù)是 Math.pow(2, 53) ，十進(jìn)制即 9007199254740992

大于 9007199254740992 的可能會(huì)丟失精度：

9007199254740992 10000000000000...000 ``// 共計(jì) 53 個(gè) 0

9007199254740992 + 1 10000000000000...001 ``// 中間 52 個(gè) 0

9007199254740992 + 2 10000000000000...010 ``// 中間 51 個(gè) 0

實(shí)際上

9007199254740992 + 1 ``// 丟失

9007199254740992 + 2 ``// 未丟失

9007199254740992 + 3 ``// 丟失

9007199254740992 + 4 ``// 未丟失

以上，可以知道看似有窮的數(shù)字, 在計(jì)算機(jī)的二進(jìn)制表示里卻是無(wú)窮的，由于存儲(chǔ)位數(shù)限制因此存在“舍去”，精度丟失就發(fā)生了。

想了解更深入的分析可以看這篇論文（你品！你細(xì)品！）： What Every Computer Scientist Should Know About Floating-Point Arithmetic

關(guān)于精度和范圍的內(nèi)容可查看 【JS的數(shù)值精度和數(shù)值范圍】

通過(guò)前面的知識(shí)補(bǔ)充，我們已經(jīng)知道：

這也就是為什么對(duì)于整數(shù)部位為10位的時(shí)間戳，通過(guò)位運(yùn)算可以進(jìn)行取整（因?yàn)槟壳皶r(shí)間戳159xxxxxxx2147483647），不存在時(shí)間戳超過(guò)范圍的問(wèn)題。但是對(duì)于13位時(shí)間戳，如 15966154471232147483647 ，此時(shí)再通過(guò)位運(yùn)算操作的時(shí)候就會(huì)導(dǎo)致異常，如：

這主要是因?yàn)樵谶M(jìn)行位運(yùn)算之前，JS會(huì)先將64bit的浮點(diǎn)數(shù) 1596615447015.01 轉(zhuǎn)為32bit的有符號(hào)整型后進(jìn)行運(yùn)算的，這個(gè)轉(zhuǎn)換過(guò)程如下：

為了驗(yàn)證上述過(guò)程，我們?cè)倥e一個(gè)例子： 1590015447015.123 0 = 877547495

將將將將！沒(méi)錯(cuò)的吧！所以JS的這個(gè)坑還真是。。。 讓人Orz

javascript中異步操作的異常怎么處理

一、JavaScript異步編程的兩個(gè)核心難點(diǎn)

異步I/O、事件驅(qū)動(dòng)使得單線(xiàn)程的JavaScript得以在不阻塞UI的情況下執(zhí)行網(wǎng)絡(luò)、文件訪(fǎng)問(wèn)功能，且使之在后端實(shí)現(xiàn)了較高的性能。然而異步風(fēng)格也引來(lái)了一些麻煩，其中比較核心的問(wèn)題是：

1、函數(shù)嵌套過(guò)深

JavaScript的異步調(diào)用基于回調(diào)函數(shù)，當(dāng)多個(gè)異步事務(wù)多級(jí)依賴(lài)時(shí)，回調(diào)函數(shù)會(huì)形成多級(jí)的嵌套，代碼變成

金字塔型結(jié)構(gòu)。這不僅使得代碼變難看難懂，更使得調(diào)試、重構(gòu)的過(guò)程充滿(mǎn)風(fēng)險(xiǎn)。

2、異常處理

回調(diào)嵌套不僅僅是使代碼變得雜亂，也使得錯(cuò)誤處理更復(fù)雜。這里主要講講異常處理。

二、異常處理

像很多時(shí)髦的語(yǔ)言一樣，JavaScript 也允許拋出異常，隨后再用一個(gè)try/catch

語(yǔ)句塊捕獲。如果拋出的異常未被捕獲，大多數(shù)JavaScript環(huán)境都會(huì)提供一個(gè)有用的堆棧軌跡。舉個(gè)例子，下面這段代碼由于'{'為無(wú)效JSON

對(duì)象而拋出異常。

?

12345678

function JSONToObject(jsonStr) { return JSON.parse(jsonStr);}var obj = JSONToObject('{');//SyntaxError: Unexpected end of input//at Object.parse (native)//at JSONToObject (/AsyncJS/stackTrace.js:2:15)//at Object.anonymous (/AsyncJS/stackTrace.js:4:11)

堆棧軌跡不僅告訴我們哪里拋出了錯(cuò)誤，而且說(shuō)明了最初出錯(cuò)的地方：第4 行代碼。遺憾的是，自頂向下地跟蹤異步錯(cuò)誤起源并不都這么直截了當(dāng)。

異步編程中可能拋出錯(cuò)誤的情況有兩種：回調(diào)函數(shù)錯(cuò)誤、異步函數(shù)錯(cuò)誤。

1、回調(diào)函數(shù)錯(cuò)誤

如果從異步回調(diào)中拋出錯(cuò)誤，會(huì)發(fā)生什么事？讓我們先來(lái)做個(gè)測(cè)試。

?

1234567

setTimeout(function A() { setTimeout(function B() { setTimeout(function C() { throw new Error('Something terrible has happened!'); }, 0); }, 0);}, 0);

上述應(yīng)用的結(jié)果是一條極其簡(jiǎn)短的堆棧軌跡。

?

12

Error: Something terrible has happened!at Timer.C (/AsyncJS/nestedErrors.js:4:13)

等等，A 和B 發(fā)生了什么事？為什么它們沒(méi)有出現(xiàn)在堆棧軌跡中？這是因?yàn)檫\(yùn)行C 的時(shí)候，異步函數(shù)的上下文已經(jīng)不存在了，A 和B 并不在內(nèi)存堆棧里。這3

個(gè)函數(shù)都是從事件隊(duì)列直接運(yùn)行的。基于同樣的理由，利用try/catch

語(yǔ)句塊并不能捕獲從異步回調(diào)中拋出的錯(cuò)誤。另外回調(diào)函數(shù)中的return也失去了意義。

?

1234567

try { setTimeout(function() { throw new Error('Catch me if you can!'); }, 0);} catch (e) {console.error(e);}

看到這里的問(wèn)題了嗎？這里的try/catch 語(yǔ)句塊只捕獲setTimeout函數(shù)自身內(nèi)部發(fā)生的那些錯(cuò)誤。因?yàn)閟etTimeout

異步地運(yùn)行其回調(diào)，所以即使延時(shí)設(shè)置為0，回調(diào)拋出的錯(cuò)誤也會(huì)直接流向應(yīng)用程序。

總的來(lái)說(shuō)，取用異步回調(diào)的函數(shù)即使包裝上try/catch 語(yǔ)句塊，也只是無(wú)用之舉。（特例是，該異步函數(shù)確實(shí)是在同步地做某些事且容易出錯(cuò)。例如，Node

的fs.watch(file,callback)就是這樣一個(gè)函數(shù)，它在目標(biāo)文件不存在時(shí)會(huì)拋出一個(gè)錯(cuò)誤。）正因?yàn)榇耍琋ode.js

中的回調(diào)幾乎總是接受一個(gè)錯(cuò)誤作為其首個(gè)參數(shù)，這樣就允許回調(diào)自己來(lái)決定如何處理這個(gè)錯(cuò)誤。

2、異步函數(shù)錯(cuò)誤

由于異步函數(shù)是立刻返回的，異步事務(wù)中發(fā)生的錯(cuò)誤是無(wú)法通過(guò)try-catch來(lái)捕捉的，只能采用由調(diào)用方提供錯(cuò)誤處理回調(diào)的方案來(lái)解決。

例如Node中常見(jiàn)的function (err, ...)

{...}回調(diào)函數(shù)，就是Node中處理錯(cuò)誤的約定：即將錯(cuò)誤作為回調(diào)函數(shù)的第一個(gè)實(shí)參返回。再比如HTML5中FileReader對(duì)象的onerror函數(shù)，會(huì)被用于處理異步讀取文件過(guò)程中的錯(cuò)誤。

舉個(gè)例子，下面這個(gè)Node 應(yīng)用嘗試異步地讀取一個(gè)文件，還負(fù)責(zé)記錄下任何錯(cuò)誤（如“文件不存在”）。

?

1234567

var fs = require('fs'); fs.readFile('fhgwgdz.txt', function(err, data) { if (err) { return console.error(err); }; console.log(data.toString('utf8'));});

客戶(hù)端JavaScript 庫(kù)的一致性要稍微差些，不過(guò)最常見(jiàn)的模式是，針對(duì)成敗這兩種情形各規(guī)定一個(gè)單獨(dú)的回調(diào)。jQuery 的Ajax

方法就遵循了這個(gè)模式。

?

1234

$.get('/data', { success: successHandler, failure: failureHandler});

不管API 形態(tài)像什么，始終要記住的是，只能在回調(diào)內(nèi)部處理源于回調(diào)的異步錯(cuò)誤。

三、未捕獲異常的處理

如果是從回調(diào)中拋出異常的，則由那個(gè)調(diào)用了回調(diào)的人負(fù)責(zé)捕獲該異常。但如果異常從未被捕獲，又會(huì)怎么樣？這時(shí)，不同的JavaScript環(huán)境有著不同的游戲規(guī)則……

1. 在瀏覽器環(huán)境中

現(xiàn)代瀏覽器會(huì)在開(kāi)發(fā)人員控制臺(tái)顯示那些未捕獲的異常，接著返回事件隊(duì)列。要想修改這種行為，可以給window.onerror

附加一個(gè)處理器。如果windows.onerror 處理器返回true，則能阻止瀏覽器的默認(rèn)錯(cuò)誤處理行為。

?

123

window.onerror = function(err) { return true; //徹底忽略所有錯(cuò)誤};

在成品應(yīng)用中， 會(huì)考慮某種JavaScript 錯(cuò)誤處理服務(wù)， 譬如Errorception。Errorception

提供了一個(gè)現(xiàn)成的windows.onerror 處理器，它向應(yīng)用服務(wù)器報(bào)告所有未捕獲的異常，接著應(yīng)用服務(wù)器發(fā)送消息通知我們。

2. 在Node.js 環(huán)境中

在Node 環(huán)境中，window.onerror 的類(lèi)似物就是process 對(duì)象的uncaughtException 事件。正常情況下，Node

應(yīng)用會(huì)因未捕獲的異常而立即退出。但只要至少還有一個(gè)uncaughtException 事件處理

器，Node 應(yīng)用就會(huì)直接返回事件隊(duì)列。

?

123

process.on('uncaughtException', function(err) { console.error(err); //避免了關(guān)停的命運(yùn)！});

但是，自Node 0.8.4 起，uncaughtException 事件就被廢棄了。據(jù)其文檔所言，對(duì)異常處理而言，uncaughtException

是一種非常粗暴的機(jī)制，請(qǐng)勿使用uncaughtException，而應(yīng)使用Domain 對(duì)象。

Domain 對(duì)象又是什么？你可能會(huì)這樣問(wèn)。Domain 對(duì)象是事件化對(duì)象，它將throw 轉(zhuǎn)化為'error'事件。下面是一個(gè)例子。

?

123456789

var myDomain = require('domain').create();myDomain.run(function() { setTimeout(function() { throw new Error('Listen to me!') }, 50);});myDomain.on('error', function(err) { console.log('Error ignored!');});

源于延時(shí)事件的throw 只是簡(jiǎn)單地觸發(fā)了Domain 對(duì)象的錯(cuò)誤處理器。

Error ignored!

很奇妙，是不是？Domain 對(duì)象讓throw

語(yǔ)句生動(dòng)了很多。不管在瀏覽器端還是服務(wù)器端，全局的異常處理器都應(yīng)被視作最后一根救命稻草。請(qǐng)僅在調(diào)試時(shí)才使用它。

四、幾種解決方案

下面對(duì)幾種解決方案的討論主要集中于上面提到的兩個(gè)核心問(wèn)題上，當(dāng)然也會(huì)考慮其他方面的因素來(lái)評(píng)判其優(yōu)缺點(diǎn)。

1、Async.js

首先是Node中非常著名的Async.js，這個(gè)庫(kù)能夠在Node中展露頭角，恐怕也得歸功于Node統(tǒng)一的錯(cuò)誤處理約定。

而在前端，一開(kāi)始并沒(méi)有形成這么統(tǒng)一的約定，因此使用Async.js的話(huà)可能需要對(duì)現(xiàn)有的庫(kù)進(jìn)行封裝。

Async.js的其實(shí)就是給回調(diào)函數(shù)的幾種常見(jiàn)使用模式加了一層包裝。比如我們需要三個(gè)前后依賴(lài)的異步操作，采用純回調(diào)函數(shù)寫(xiě)法如下：

?

12345678910111213141516

asyncOpA(a, b, (err, result) = { if (err) { handleErrorA(err); } asyncOpB(c, result, (err, result) = { if (err) { handleErrorB(err); } asyncOpB(d, result, (err, result) = { if (err) { handlerErrorC(err); } finalOp(result); }); });});

如果我們采用async庫(kù)來(lái)做：

?

12345678910111213141516171819202122

async.waterfall([ (cb) = { asyncOpA(a, b, (err, result) = { cb(err, c, result); }); }, (c, lastResult, cb) = { asyncOpB(c, lastResult, (err, result) = { cb(err, d, result); }) }, (d, lastResult, cb) = { asyncOpC(d, lastResult, (err, result) = { cb(err, result); }); }], (err, finalResult) = { if (err) { handlerError(err); } finalOp(finalResult);});

可以看到，回調(diào)函數(shù)由原來(lái)的橫向發(fā)展轉(zhuǎn)變?yōu)榭v向發(fā)展，同時(shí)錯(cuò)誤被統(tǒng)一傳遞到最后的處理函數(shù)中。

其原理是，將函數(shù)數(shù)組中的后一個(gè)函數(shù)包裝后作為前一個(gè)函數(shù)的末參數(shù)cb傳入，同時(shí)要求：

每一個(gè)函數(shù)都應(yīng)當(dāng)執(zhí)行其cb參數(shù);cb的第一個(gè)參數(shù)用來(lái)傳遞錯(cuò)誤。我們可以自己寫(xiě)一個(gè)async.waterfall的實(shí)現(xiàn)：

?

12345678910111213141516171819202122

let async = { waterfall: (methods, finalCb = _emptyFunction) = { if (!_isArray(methods)) { return finalCb(new Error('First argument to waterfall must be an array of functions')); } if (!methods.length) { return finalCb(); } function wrap(n) { if (n === methods.length) { return finalCb; } return function (err, ...args) { if (err) { return finalCb(err); } methods[n](...args, wrap(n + 1)); } } wrap(0)(false); }};

Async.js還有series/parallel/whilst等多種流程控制方法，來(lái)實(shí)現(xiàn)常見(jiàn)的異步協(xié)作。

Async.js的問(wèn)題：

在外在上依然沒(méi)有擺脫回調(diào)函數(shù)，只是將其從橫向發(fā)展變?yōu)榭v向，還是需要程序員熟練異步回調(diào)風(fēng)格。

錯(cuò)誤處理上仍然沒(méi)有利用上try-catch和throw，依賴(lài)于“回調(diào)函數(shù)的第一個(gè)參數(shù)用來(lái)傳遞錯(cuò)誤”這樣的一個(gè)約定。

2、Promise方案

ES6的Promise來(lái)源于Promise/A+。使用Promise來(lái)進(jìn)行異步流程控制，有幾個(gè)需要注意的問(wèn)題，

把前面提到的功能用Promise來(lái)實(shí)現(xiàn)，需要先包裝異步函數(shù)，使之能返回一個(gè)Promise：

?

12345678910

function toPromiseStyle(fn) { return (...args) = { return new Promise((resolve, reject) = { fn(...args, (err, result) = { if (err) reject(err); resolve(result); }) }); };}

這個(gè)函數(shù)可以把符合下述規(guī)則的異步函數(shù)轉(zhuǎn)換為返回Promise的函數(shù)：

回調(diào)函數(shù)的第一個(gè)參數(shù)用于傳遞錯(cuò)誤，第二個(gè)參數(shù)用于傳遞正常的結(jié)果。接著就可以進(jìn)行操作了：

?

123456789101112131415

let [opA, opB, opC] = [asyncOpA, asyncOpB, asyncOpC].map((fn) = toPromiseStyle(fn)); opA(a, b) .then((res) = { return opB(c, res); }) .then((res) = { return opC(d, res); }) .then((res) = { return finalOp(res); }) .catch((err) = { handleError(err); });

通過(guò)Promise，原來(lái)明顯的異步回調(diào)函數(shù)風(fēng)格顯得更像同步編程風(fēng)格，我們只需要使用then方法將結(jié)果傳遞下去即可，同時(shí)return也有了相應(yīng)的意義：

在每一個(gè)then的onFullfilled函數(shù)（以及onRejected）里的return，都會(huì)為下一個(gè)then的onFullfilled函數(shù)（以及onRejected）的參數(shù)設(shè)定好值。

如此一來(lái)，return、try-catch/throw都可以使用了，但catch是以方法的形式出現(xiàn)，還是不盡如人意。

3、Generator方案

ES6引入的Generator可以理解為可在運(yùn)行中轉(zhuǎn)移控制權(quán)給其他代碼，并在需要的時(shí)候返回繼續(xù)執(zhí)行的函數(shù)。利用Generator可以實(shí)現(xiàn)協(xié)程的功能。

將Generator與Promise結(jié)合，可以進(jìn)一步將異步代碼轉(zhuǎn)化為同步風(fēng)格：

?

1234567891011

function* getResult() { let res, a, b, c, d; try { res = yield opA(a, b); res = yield opB(c, res); res = yield opC(d); return res; } catch (err) { return handleError(err); }}

然而我們還需要一個(gè)可以自動(dòng)運(yùn)行Generator的函數(shù)：

?

123456789101112131415161718192021222324252627282930

function spawn(genF, ...args) { return new Promise((resolve, reject) = { let gen = genF(...args); function next(fn) { try { let r = fn(); if (r.done) { resolve(r.value); } Promise.resolve(r.value) .then((v) = { next(() = { return gen.next(v); }); }).catch((err) = { next(() = { return gen.throw(err); }) }); } catch (err) { reject(err); } } next(() = { return gen.next(undefined); }); });}

用這個(gè)函數(shù)來(lái)調(diào)用Generator即可：

?

1234567

spawn(getResult) .then((res) = { finalOp(res); }) .catch((err) = { handleFinalOpError(err); });

可見(jiàn)try-catch和return實(shí)際上已經(jīng)以其原本面貌回到了代碼中，在代碼形式上也已經(jīng)看不到異步風(fēng)格的痕跡。

類(lèi)似的功能有co/task.js等庫(kù)實(shí)現(xiàn)。

4、ES7的async/await

ES7中將會(huì)引入async function和await關(guān)鍵字，利用這個(gè)功能，我們可以輕松寫(xiě)出同步風(fēng)格的代碼，

同時(shí)依然可以利用原有的異步I/O機(jī)制。

采用async function，我們可以將之前的代碼寫(xiě)成這樣：

?

12345678910111213

async function getResult() { let res, a, b, c, d; try { res = await opA(a, b); res = await opB(c, res); res = await opC(d); return res; } catch (err) { return handleError(err); }} getResult();

和Generator Promise方案看起來(lái)沒(méi)有太大區(qū)別，只是關(guān)鍵字換了換。

實(shí)際上async

function就是對(duì)Generator方案的一個(gè)官方認(rèn)可，將之作為語(yǔ)言?xún)?nèi)置功能。

async function的缺點(diǎn)：

await只能在async function內(nèi)部使用，因此一旦你寫(xiě)了幾個(gè)async function，或者使用了依賴(lài)于async

function的庫(kù)，那你很可能會(huì)需要更多的async function。

目前處于提案階段的async

function還沒(méi)有得到任何瀏覽器或Node.JS/io.js的支持。Babel轉(zhuǎn)碼器也需要打開(kāi)實(shí)驗(yàn)選項(xiàng)，并且對(duì)于不支持Generator的瀏覽器來(lái)說(shuō)，還需要引進(jìn)一層厚厚的regenerator

runtime，想在前端生產(chǎn)環(huán)境得到應(yīng)用還需要時(shí)間。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助。

文章題目：javascript異常,js異常處理語(yǔ)句
當(dāng)前地址：http://chinadenli.net/article42/dsegchc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開(kāi)發(fā)、營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)公司、網(wǎng)站營(yíng)銷(xiāo)、網(wǎng)站導(dǎo)航、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)