程序员常常会误解包含在许多 System.IO 类中的 Read() 及相关方法。大部分错误和异常事件在 .NET 结果中都会被作为一个异常抛出。（这是 .NET 相对于 C 语言等编程语言的优势：各种异常更加便于程序员考虑是哪里出现了问题。）但是，如果只有少量的数据可用（可读），stream 和 reader 类并不认为这是异常的情况。这些类只是将这些少量的数据添加到返回值缓冲区，并且将返回值设置为读取的字节或字符数。所以，并不能保证返回的数据量一定等于请求的数据量。

这样，程序员就需要检查 Read() 和其他 IO 方法的返回值，以确保接收到期望的数据量。
示例 1：下列代码会在一组用户中进行循环，读取每个用户的私人数据文件。程序员假设这些文件始终为 1000 字节，从而忽略了检查 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() 时出现缓冲区溢出。

对于程序员而言，检查返回值以确保从方法调用返回预期状态非常重要。

示例 1：下列代码会在一组用户中进行循环，读取每个用户的私人数据文件。程序员假设这些文件始终为 1000 字节，从而忽略了检查 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)
}