第八輪迴 相信它就像預期那樣運行

在這一個輪迴我們與欺詐之人相遇--它們都彼此被困在自己的火焰之中。

這一輪迴的廣度和深度或許超過了大部分人的預期。原因包括：

• 向下兼容性。這裏有大概20年的兼容問題需要考慮。如果你是一個新的使用者，你應該會認爲這些粗糙的瑕疵應該被理順而不管它是什麼。如果一個新版本的R破壞了你之前可以成功運行的代碼，你會有不同的想法。哪些較大的碎片已經被打平，但是仍然還有大量的小細節需要調節。
• R需要同時滿足交互性和可編程性。這就會出現緊張的局勢。一部分函數採用了特殊的安排以使交互性更加簡便。如果在一個函數裏邊使用這些函數，這些函數可能會出現問題。它們也會促進錯誤的預期。
• R 做了很多。

在這個輪迴裏，我們將會遇到大量的鬼混，野獸和惡魔。這些通常可以用browser()來驅除。將browser()放在函數的相應位置可以查看這個點位的函數運行情況。一個很相似的替代函數是recover() 。brower()可以讓你看到函數中brower()被放置位置的對象的信息。recover()不僅可以讓你看到這些，還會讓你看到該函數的調用者和其他所有活動的函數中的對象信息。

      

在你寫代碼的時候，自由地使用browser()、recover()、cat()和print()將會幫助將你的預期和R的預期合二爲一。

 

  一個非常方便的方法是使用trace()。比如，如果在myFun()最後瀏覽對象很方便的話，你可以這樣做：

   trace(myFun, exit=quote(browser()))

 

你可以用一下代碼進行自定義跟蹤：

   trace(myFun, edit=TRUE)

     

 如果你遭遇了一個錯誤，那麼調試是合適的選擇。最少有兩種方法做調試。第一個是查看錯誤出現地方的運行信息。爲了這個目標或許可以設置錯誤選項。兩個最可能使用的選擇是：

   options(error=recover)

或者

   options(error=dump.frames)

兩者之間的不同之處在於，使用recover你已經自動地處於debug模式，但是使用dump.frames你開始debug通過執行：

   debugger()

在這兩種情況下，你都會對活動的函數的幀（環境）進行選擇來進行檢查。

你可以用以下代碼強制R將warnings視爲errors：

   options(warn=2)

如果你想在你的.First函數中設置錯誤選項，你需要一個小技巧，因爲在.First()運行的時候，並不是所有事情都到位：

   options(error=expression(recover()))

或者

   options(error=expression(dump.frames()))

第二個調試方法是讓函數一步一步執行。如果你想逐步執行myfun()，這麼做：

   debug(myfun)

然後執行包含mufun()的語句。當你在做調試的時候，運行：

   undebug(myfun)

這種調試方法的更多的版本將會在debug包中被發現。