程式設計師常會誤解許多 System.IO 類別中的 Read() 及相關方法。在.NET 中，大部分的錯誤和不尋常的事件會當成異常狀況拋出。(此為.NET 優於其他語言 (如 C 語言) 的優點之一：異常可讓程式設計師更容易思考是哪裡出錯了。)但是，如果只有少量的資料可用，stream 和 reader 類別便不認為這是不尋常或異常的情況。這些類別只會將這些小量的資料加入回傳緩衝區，並且把回傳值設為讀取的位元組或字元數。因此，並不能保證回傳的資料量等於要求的資料量。

這樣一來，程式設計師必須檢查從 Read() 回傳的值以及其他 IO 方法，並確保他們能夠接收到預期的資料數量。
範例 1：以下程式碼會在一組使用者中循環，讀取每個使用者的私人資料檔案。程式設計師假設檔案的大小始終為 1KB，因而忽略了 Read() 的回傳值。如果攻擊者可以建立更小的檔案，那麼程式會回收前一個使用者剩餘的資料，並將這些資料當作攻擊者的所有物來處理。

char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
    string userName = (string) i.Current();
    string pFileName = PFILE_ROOT + "/" + userName;
    StreamReader sr = new StreamReader(pFileName);
    sr.Read(byteArray,0,1024);//the file is always 1k bytes
    sr.Close();
    processPFile(userName, byteArray);
}

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1：假設有下列程式碼：

char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

程式設計師希望當 fgets() 傳回值時，buf 將包含一個以 Null 為結束標誌的字串，並且該字串的長度小於或等於 9。但是如果發生了 I/O 錯誤，fgets() 將不會傳回以 Null 為結束標誌的 buf。此外，如果在任何字元被讀取之前，已經到達檔案的結尾處，那麼 fgets() 在傳回時不會在 buf 中寫入任何的內容。在這兩種情況下，fgets() 會藉由傳回 NULL 來標示那些異常情況，但是在這段程式碼中，這個警告將不會被提出。由於在 buf 中缺少一個 Null 終端子，這就可能導致在隨後呼叫 strcpy() 時出現 Buffer Overflow。

程式設計師必須檢查回傳的值，以確保從方法呼叫傳回預期的狀態。

範例 1：以下程式碼會在一組使用者中循環，讀取每個使用者的私人資料檔案。程式設計師會假設這些檔案大小一直剛好是 1KB，因而忽略了來自 read() 的回傳值。如果攻擊者可以建立更小的檔案，那麼程式會回收前一個使用者剩餘的資料，並將這些資料當作攻擊者的所有物來處理。

var fis: FileInputStream
val byteArray = ByteArray(1023)
val i: Iterator<*> = users.iterator()
while (i.hasNext()) {
    val userName = i.next() as String
    val pFileName: String = PFILE_ROOT.toString() + "/" + userName
    val fis = FileInputStream(pFileName)
    fis.read(byteArray) // the file is always 0k bytes
    fis.close()
    processPFile(userName, byteArray)
}