Share via


System.Exception.Data 屬性

本文提供此 API 參考文件的補充備註。

System.Collections.IDictionary使用 屬性傳Data回的對象來儲存和擷取與例外狀況相關的補充資訊。 資訊的格式為任意數目的使用者定義索引鍵/值組。 每個索引鍵/值組的索引鍵元件通常是識別字串,而配對的值元件可以是任何類型的物件。

金鑰/值組安全性

儲存在 屬性所 Data 傳回之集合中的索引鍵/值組並不安全。 如果您的應用程式呼叫巢狀的例程系列,而且每個例程都包含例外狀況處理程式,則產生的呼叫堆疊會包含這些例外狀況處理程式的階層。 如果較低層級的例程擲回例外狀況,則呼叫堆棧階層中的任何上層例外狀況處理程式都可以讀取和/或修改任何其他例外狀況處理程式儲存在集合中的索引鍵/值組。 這表示您必須保證索引鍵/值組中的資訊不是機密的,而且如果機碼/值組中的資訊損毀,您的應用程式將會正確運作。

索引鍵衝突

當不同的例外狀況處理程式指定相同的索引鍵來存取索引鍵/值組時,就會發生索引鍵衝突。 開發應用程式時請小心,因為索引鍵衝突的後果是較低層級的例外狀況處理程式可能會不小心與較高層級的例外狀況處理程序通訊,而且此通訊可能會導致細微的程序錯誤。 不過,如果您謹慎,您可以使用密鑰衝突來增強應用程式。

避免金鑰衝突

藉由採用命名慣例來產生索引鍵/值組的唯一索引鍵,以避免密鑰衝突。 例如,命名慣例可能會產生索引鍵,其中包含以句點分隔的應用程式名稱、提供配對補充資訊的方法,以及唯一標識符。

假設兩個名為 Products 和 Suppliers 的應用程式,每個應用程式都有一個名為 Sales 的方法。 Products 應用程式中的 Sales 方法會提供產品的標識碼(庫存單位或 SKU)。 供應商應用程式中的 Sales 方法會提供供應商的識別碼或 SID。 因此,此範例的命名慣例會產生密鑰 “Products.Sales.SKU” 和 “Suppliers.Sales.SID”。

惡意探索金鑰衝突

利用一或多個特殊、預先排列的索引鍵來控制處理,來惡意探索密鑰衝突。 假設在一個案例中,呼叫堆疊階層中的最高層級例外狀況處理程式會攔截較低層級例外狀況處理程序擲回的所有例外狀況。 如果具有特殊索引鍵的索引鍵/值組存在,則高階例外狀況處理程式會以某些非標準方式格式化物件中的 IDictionary 剩餘索引鍵/值組;否則,其餘索引鍵/值組會以某種一般方式格式化。

現在假設在另一個案例中,呼叫堆疊階層的每個層級的例外狀況處理程式會攔截下一個較低層級例外狀況處理程序擲回的例外狀況。 此外,每個例外狀況處理程式都知道 屬性所 Data 傳回的集合包含一組索引鍵/值組,可使用預先排列的索引鍵集來存取。

每個例外狀況處理程式都會使用預先排列的索引鍵集來更新對應索引鍵/值組的值元件,以及該例外狀況處理程式唯一的資訊。 更新程式完成之後,例外狀況處理程式會將例外狀況擲回至下一個較高層級的例外狀況處理程式。 最後,最高層級的例外狀況處理程式會存取索引鍵/值組,並顯示來自所有較低層級例外狀況處理程式的合併更新資訊。