原題地址: http://www.cnblogs.com/ziyunfei/archive/2012/10/04/2711370.html
有興趣的同學可以去做一做.
本帖為,本人給出的答案貼.並非原作者給出答案. 僅供參考. 歡迎討論.
1. TypeError
原因: Function.prototype.toString不是一個通用方法,這意味着,該方法被調用時,其this,如果不是一個函數對象,則要拋出TypeError異常.
2. TypeError.
原因:
new String(expression);
是需要對expression 解釋執行，並對其結果進行 內部ToString運算. 其調用棧為 ToString(value) -> ToPrimitive(value, hint string)
ToPrimitive(value) 這里,因參數為非原始類型(是個對象),又因hint string,所以會優先調用目標對象的toString方法,如果結果仍然不是一個原始類型,則再次去調用其valueOf方法,如果返回結果仍然不是一個原始類型則拋出TypeError異常.因為題中.參數是個對象,且valueOf,和toString都被重寫,且都不返回一個原始類型.so ...異常是必然的.
3. string
因為"+"加發,對於對於兩個運算元,是直接調用ToPrimitive的,而Date類型進行ToPrimitive運算的過程.沒有明確指明hint .那么就視為 hint string. 所以優先調用其toString方法.自然是字符串結果.至於toString的輸出內容則是依賴實現的.但總是要返回一個string就對了. 啥時候會有hint Number? new Date - new Date 就會了. 區別在於 "-" 減法會對兩個運算元,調用內部抽象運算 ToNumber. 則會導致調用ToPrimitive時,顯式提供 hint Number 作為參數.
4. undefined
似乎沒啥好說的, void 運算符,的運算過程很明確. 對運算元解釋執行的結果求值后. 直接返回undefined . 這也是為啥我反對使用 void function(){}(); 作為IIFE的用法.因為void並不像很多人認為的那樣, 比其他一些IIFE的寫法,少一次運算.真正少一次運算的是分組運算符.也就是最古老的(function(){}()) .
5. [object Object]
似乎沒啥好說的. new F 肯定 object ...
6. RangeError
簡單來說js的數組要求length 的范圍在0 - 2的32次方-1 之間.
那么對於 [].length = xxx 這本質是以'length'為參數,調用數組對象自身的 [PUT]方法, 並把xxx作為value. 這是個過程中會調用
ToUint32(xxx) 然后再去與 ToNumber(xxx) 的結果做對比.如果不相等.則拋出RangeError. 內部運算 ToUint32 是不會返回負數的.所以與ToNumber的結果一定不同. so ...
7. false.
這道題,我甚至覺得根本無需解釋的樣子..
位運算只對 2的32次方以內的數字有效. 所以D已經越界了. 越界后 D | D 的結果, 就不可能與其自身會相等了.
8. _string__string_
String.prototype.replace 是一個異常復雜的方法.
這里唯一要提醒的就是那組替換字符:
$’ 替換為匹配位之后的子串
有興趣可以看下這個表:
$$ $
$& The matched substring.
$‘ The portion of string that precedes the matched substring.
$’ The portion of string that follows the matched substring.
$n The nth capture, where n is a single digit 1-9 and $n is not followed by a decimal
digit. If n≤m and the nth capture is undefined, use the empty string instead. If n>m,
the result is implementation-defined.$nn The nnth capture, where nn is a two-digit decimal number 01-99. If nn≤m and the
nnth capture is undefined, use the empty string instead. If nn>m, the result is
implementation-defined
9. function
只要記住一點
eval code 在ES3 里的定義十分簡單. 內部依然有函數聲明的概念. 所以這個結果大家應該不會選錯的樣子.
10. 說實話,如果嚴格考慮標准,而不是我們熟知的那些ES3引擎實現的話.選項中沒有正確答案.
原因如下 ：
debugger; ES3是作為關鍵字中的預保留字定義的. 所以在ES3的引擎中直接使用,本來應該拋出異常的.只不過即使IE6時代的jscript引擎,(ES3)引擎也都實現了這玩意. ES5,把他正式定義了.
所以, 僅從標准角度來看.答案應該是,確認拋異常,而不是可能拋異常.只是ES3的瀏覽器的實現幾乎都與ES5的規范一致.所以其實ES5的規范，在這里是從善如流.即當你有一個調試器存在時,則進入斷點.否則,無視這玩意..