&“死程序不會(huì)說謊”在GUI程序

解答動(dòng)態(tài)

• 

  引用書中的同一段話（我的重點(diǎn)）：
  盡快發(fā)現(xiàn)問題的好處之一是你可以更早崩潰，崩潰通常是你能做的最好的事情。另一種方法可能是繼續(xù)，將損壞的數(shù)據(jù)寫入某個(gè)重要的數(shù)據(jù)庫，或者命令洗衣機(jī)進(jìn)入第二十個(gè)連續(xù)的旋轉(zhuǎn)周期。
  …當(dāng)您的代碼發(fā)現(xiàn)原本不可能的事情剛剛發(fā)生時(shí)，您的程序?qū)⒉辉倏尚小�從這一點(diǎn)開始，它所做的任何事情都是可疑的，所以盡可能快地終止它。
  當(dāng)程序員使用斷言時(shí)，他們會(huì)說“這永遠(yuǎn)不會(huì)發(fā)生”。通常，在這些條件下終止程序是一種適當(dāng)?shù)姆磻?yīng)，尤其是程序員的斷言因?yàn)槲粗�的原因被違背了。對(duì)于帶有GUI的程序來說，這一點(diǎn)與對(duì)于控制臺(tái)程序或服務(wù)來說是一樣的。
  對(duì)于正常的異常，問題變得和以前一樣：我們能從這個(gè)異常中有意義地恢復(fù)嗎？這取決于；異常是在寫入關(guān)鍵數(shù)據(jù)庫的過程中發(fā)生的，還是用戶只是給了我們一個(gè)不存在的文件名？我認(rèn)為你問錯(cuò)了問題。很明顯，這一原則尤其適用于GUI應(yīng)用程序的上下文，我們最好問問它是否也適用于非GUI應(yīng)用程序的上下文。為什么？因?yàn)閷?duì)于GUI程序，通常有一個(gè)用戶坐在系統(tǒng)前面，當(dāng)崩潰發(fā)生時(shí)（用戶看到您提到的“適當(dāng)?shù)腻e(cuò)誤消息”），他們可以立即采取一些明智的措施。根據(jù)應(yīng)用程序的類型，此操作可能是
  重新啟動(dòng)程序并重試是否會(huì)再次發(fā)生故障
  如果可以避免此問題
  檢查是否丟失了一些數(shù)據(jù)并啟動(dòng)恢復(fù)過程
  呼叫熱線，或者給他們發(fā)一封電子郵件，告訴他們錯(cuò)誤信息和所發(fā)生的情況使用不同的程序（或者可能根本沒有軟件），只要沒有可用的bug修復(fù)2 或任何對(duì)給定系統(tǒng)最有意義的東西。
  對(duì)于非GUI應(yīng)用程序，情況就稍微復(fù)雜一點(diǎn)。它們通常需要一些自動(dòng)故障處理，因?yàn)橄到y(tǒng)是無人值守的。為了以可靠的方式實(shí)現(xiàn)這一點(diǎn)，通常使用多個(gè)進(jìn)程，其中至少有一個(gè)不太復(fù)雜且以健壯的方式編寫的進(jìn)程具有或的角色，而其他進(jìn)程具有工作者的角色。工作進(jìn)程仍然可以遵循“崩潰早”原則。對(duì)于管制員來說，工人撞車是一種預(yù)期行為。因此，可以應(yīng)用一些啟發(fā)式方法來做出相應(yīng)的反應(yīng)（通常，它會(huì)自動(dòng)執(zhí)行上面列出的操作，這些操作是人類應(yīng)用于崩潰的GUI程序的）。為了解決這個(gè)問題，除了worker controller之外，還有其他模型，但它們都使用多個(gè)進(jìn)程。
  今天，甚至許多復(fù)雜的GUI應(yīng)用程序（如web瀏覽器、字處理器或其他幾十個(gè)程序）都是這樣實(shí)現(xiàn)的：它們的某些部分在外部進(jìn)程中運(yùn)行。當(dāng)這樣一個(gè)進(jìn)程“提前崩潰”時(shí)，通常不必關(guān)閉整個(gè)程序，只需終止進(jìn)程，并直接在GUI中給用戶一些我提到的選項(xiàng)就足夠了。
  
• 

  簡(jiǎn)而言之，提前崩潰也是GUI的一種可取方法，但是導(dǎo)致這種情況的條件應(yīng)該盡可能地減少。更詳細(xì)地說，如果失去控制，系統(tǒng)會(huì)崩潰。一般來說，GUI的目標(biāo)是讓用戶的生活更輕松，系統(tǒng)更容易理解。當(dāng)崩潰時(shí)，它不再是圖形化的，用戶只會(huì)感到沮喪。因此，推廣這種方法似乎有點(diǎn)奇怪。
  但是，當(dāng)系統(tǒng)內(nèi)存耗盡時(shí)，您是否嘗試過GUI應(yīng)用程序？或者當(dāng)沒有可用的windows資源時(shí)，因?yàn)榫浔�泄漏？一個(gè)窗口打開，拼命地通知您一個(gè)錯(cuò)誤，但什么也沒有出現(xiàn)，因?yàn)闆]有資源了�；蛘吒�糟：另一個(gè)窗口試圖通知您錯(cuò)誤窗口上的錯(cuò)誤。不要談?wù)撈渌�可能需要處理的非GUI事件。
  在這種情況下，早期崩潰是最好的選擇。因此，Andy Hunt的實(shí)用程序員建議是一個(gè)很好的建議，同樣適用于GUI.
  ，但是要使系統(tǒng)健壯，以避免事情變得如此糟糕，導(dǎo)致這種絕境和突然終止的情況應(yīng)盡可能在無法預(yù)防和無法恢復(fù)的范圍內(nèi)錯(cuò)誤：許多錯(cuò)誤通常導(dǎo)致這種絕望局面的情況是可以避免的，例如通過清除輸入、防止使用壞參數(shù)、驗(yàn)證OS或API函數(shù)是否可以在根據(jù)他們的行為繼續(xù)之前，必須無誤地完成成功。很多如果仔細(xì)考慮在哪一級(jí)可能出現(xiàn)什么問題，不利的情況是可以恢復(fù)的。這就是例外情況鼓勵(lì)我們做的：例如，可能被零除是意外的，但它應(yīng)該需要更多的崩潰系統(tǒng)。 因此，如果不立即考慮錯(cuò)誤預(yù)防措施，就不能考慮您的具體問題。因此，請(qǐng)將這些建議與基本的防御性編程實(shí)踐結(jié)合起來，例如在調(diào)用后驗(yàn)證參數(shù)和驗(yàn)證錯(cuò)誤狀態(tài)（WinAPI函數(shù)的調(diào)用頻率是多少，只是忽略返回狀態(tài)，導(dǎo)致兩個(gè)聲明后，一個(gè)不可恢復(fù)的，但完全可以預(yù)防的情況）。
  當(dāng)它的任務(wù)關(guān)鍵 證明這是可行的？以期望具有高可靠性的軟件為例：OS。上一年，你有多少次在微軟Windows下出現(xiàn)BSOD或者在Mac上意外重啟系統(tǒng)？與20年前相比，
  已經(jīng)投入了大量資金，以首先防止不可控（質(zhì)量保證+防御編程），并使這些系統(tǒng)強(qiáng)大，能夠應(yīng)對(duì)出現(xiàn)的情況（設(shè)計(jì)中的恢復(fù)策略、具有組件的體系結(jié)構(gòu)，因此，在最壞的情況下，可以重新啟動(dòng)一個(gè)組件，而不是使整個(gè)系統(tǒng)崩潰）。。。在設(shè)計(jì)軟件時(shí)，我用斷言（和類似的“可疑防御”）填充代碼，在部署時(shí)我將它們留在代碼中。我的軟件總是在尋找麻煩，因?yàn)椤败浖�本身”�?shí)際上是唯一能夠意識(shí)到某個(gè)錯(cuò)誤并引起注意的一方。
  您的應(yīng)用程序應(yīng)該有一個(gè)“最外層”異常處理程序，它將“最后的異�！保荒鷳�(yīng)該仔細(xì)地為這些異常制定出一個(gè)有意義的類層次結(jié)構(gòu)——超越語言的內(nèi)置部分。在捕獲您希望在代碼的特定部分中找到的異常時(shí)要特別注意，允許意外異常冒泡到更高級(jí)別的處理程序。找出一個(gè)策略來處理它們，即使其中一個(gè)是“我們現(xiàn)在別無選擇，只能終止程序�！�
  “異常”機(jī)制也可以用作某種轉(zhuǎn)到。例如，當(dāng)您意識(shí)到用戶犯了錯(cuò)誤時(shí)，您可能會(huì)深深地沉浸在代碼中。您可以拋出適當(dāng)類的異常，知道它最終將被所選處理程序捕獲。您可以將參數(shù)附加到exception對(duì)象，我建議一個(gè)（dummy…）參數(shù)應(yīng)該允許您唯一地標(biāo)識(shí)代碼中拋出它的點(diǎn)。這實(shí)際上是一個(gè)非常干凈的方法來處理這些“特殊”的情況。
  “如果出了什么問題，一個(gè)的棒球會(huì)從某處飛向接球手的手套。因此，如果你沒有看到這樣的棒球，那就沒有什么問題，因?yàn)槊總�(gè)人都在找麻煩，唯一要做的就是舉手說“我不知道該做什么”，然后停止做你想做的事情。
  A GUI由不同的子系統(tǒng)組成，所有這些系統(tǒng)都應(yīng)該在他們不知道如何處理的情況下做同樣的事情——舉起他們比喻的手，比喻地說“我不知道該怎么辦”。最終，該消息要么會(huì)丟失，要么會(huì)到達(dá)進(jìn)程中知道要做什么的部分。
  不管是GUI應(yīng)用程序、命令行中的函數(shù)還是AWS函數(shù)。正如這句話所暗示的，其他任何事情都是謊言。被告知做某事時(shí)，系統(tǒng)要么報(bào)告“做了”，而事實(shí)上他們沒有，要么就再也不說什么了。這兩個(gè)都是謊言。
  過早崩潰，經(jīng)常崩潰。
  
• 

  這要看情況而定。從理論上講，一切皆有可能，終止整個(gè)過程
• End