我是否应该使用C#中的异常来执行基类兼容性？

Question

一方面，我被告知在C#中的异常是“昂贵的”，但另一方面，我被困在如何实现这个问题上。

我的问题是:我正在做一个Stream的嘲讽，它包装了一个NetworkStream。现在，我面临的问题是：Read(byte[] buffer, int offset, int count)。函数的Stream文档：

返回：

..。如果已到达流的末尾，则为零(0)。

问题是，在我正在实现的协议中，远程端可以发送"end of record“令牌，或者”请响应“令牌。显然，如果这发生在Read()的开头，这会导致问题，因为我需要从函数返回，而且我没有读取任何内容，所以我需要返回0，这意味着流已经完成，但它不是.在这种情况下，EndOfRecordException或类似的方法是否合理？在本例中，如果在遇到此令牌时(在Read()调用开始时，并确保这些令牌总是在开始时提前返回)抛出该令牌，那么这些令牌的处理方式就会有某种模式。

编辑：，就其价值而言，这些令牌通常每秒经过3-10次。充其量，我预计每秒不会超过25。

Answer 1

异常并没有那么昂贵--但它们也不一定是管理预期/正常流的最佳方法。

在我看来，这听起来似乎并不是真正实现Stream --而是将流封装到“读取器”中。我可能倾向于编写一个特定于协议的读取器类，使用适当的方法检测记录的结束，或者编写Try...方法来获取数据或返回false。

Answer 2

如果您的类关心记录，听起来您不应该真的从Stream派生。流通常根本不解释它们的数据--它们只是数据从一个地方到另一个地方的传输机制。

在Java中有一些类似于ZipInputStream的情况，当单个InputStream实际上有几个流时，结果会非常混乱，而且您可以跳过它们之间的流。在我的经验中，这样的API使用起来很糟糕。提供一个单独的类来实现“记录拆分”，它可以为记录中的数据提供流，对我来说听起来更清晰。然后，每个流可以与正常流保持一致的行为。不需要新的例外。

然而，我只是根据有限的可用信息来猜测您的上下文。如果你能给出更多的更大的细节，这将有所帮助。

Answer 3

表演没什么大不了的，但是.例外是为了，嗯，例外。“不寻常”的情况。如果这是底层流的行为方式，那么您的流应该能够处理它。如果可以的话，它应该自己处理。如果没有，您可以让用户设置一些回调或在收到“请响应”令牌时被调用的东西。