Question

我记得我在某处读过从用户代码中抛出任何System.SystemException派生的异常是一种不好的做法，因为用户代码应该只抛出应用程序异常。

我们有一个使用GPU的本机库。它可能会返回一个错误代码，表明我们没有GPU内存。我们希望将此错误代码转换为.Net异常。

这是我能想到的可能例外：

System.OutOfMemoryException
System.InvalidOperationException合适的文字
自定义异常（基于InvalidOperationException）

哪一个是最好的，为什么？

Answer 1

投掷System.OutOfMemoryException不是理想的选择。使用您的库的程序员可能会通过从内存中清除一些非必要对象并再次尝试来对System.InvalidOperationException作出反应。但是，在你的情况下，它是GPU内存，而不是系统内存，所以他们的尝试没有机会工作。

如果用户可以直接或间接地从GPU内存中卸载内容，则自定义异常方法（第三种）提供了最干净的选择。如果他们完全无法控制它，即异常基本上是“你死了”的消息，那么=iif(Fields!SecurtiyIncidents.Value = 0,"",Fields!SecurtiyIncidents.Value)也是一个不错的选择。

Answer 2

提升OutOfMemoryException是最糟糕的选择。这样做的原因是这种异常几乎不可能在一般情况下恢复，对于客户端来说，确定系统是否内存不足或者你只是滥用了这种异常类型是非常困难的，特别是因为客户端不会期待这种行为。

提升InvalidOperationException是更好的事情，因为客户端将能够处理这个问题（通过将计算卸载到其他地方或在CPU中执行所需的东西，可能使用不同的库）。但是，如果异常是InvalidOperationException，则此异常类型很可能也被其他库使用或由BCL使用。因此，客户端必须通过解析错误消息来对此异常做出反应，这是不可靠的。

因此，最佳解决方案是自定义异常类型，因为这将使客户端能够捕获此异常类型并从这种情况中恢复或告诉用户问题是什么。您是否认为这是无效操作的特殊情况取决于您。就个人而言，我不会让异常从InvalidOperationException继承，而是直接从Exception继承。

Answer 3

抛出的异常应该是提供信息的，所以让我们寻找候选人：

System.OutOfMemoryException

https://msdn.microsoft.com/en-us/library/system.outofmemoryexception(v=vs.110).aspx

OutOfMemoryException异常有两个主要原因：


您正在尝试将StringBuilder对象扩展到其StringBuilder.MaxCapacity属性定义的长度之外。

公共语言运行库无法分配足够的连续内存来成功执行操作。这个例外可以   由任何需要a的属性赋值或方法调用抛出   内存分配。有关原因的更多信息   OutOfMemoryException异常，请参阅＆＃34; Out of Memory＆＃34;不参考   物理记忆。

阅读本文之后，我认为System.OutOfMemoryException是一个非常错误的候选人：误导，因为您的案例中的问题是 GPU 而不是 RAM 即可。

第二个念珠菌

System.InvalidOperationException

https://msdn.microsoft.com/en-us/library/system.invalidoperationexception(v=vs.110).aspx

方法调用无效时抛出的异常对象的当前状态。

另一个小姐;状态还可以，它的GPU没有足够的内存。

所以我建议您实现自己的自定义异常，但不是基于System.InvalidOperationException，而是基于Exception通过abstract GpuException：< / p>

   Exception
     GpuException               // Abstract (wrong GPU, lack of support etc.)
       GpuOutOfMemoryException  // Not enough memory on board

从应用程序代码好的设计中抛出OutOfMemoryException

3 个答案: