我有以下代码,我正在尝试提供有关异常的更多信息:
int id = 5;
try
{
var record = db.MyTable
.Where(x.Id == 5)
.Single();
// more code here ...
}
catch (InvalidOperationException ex)
{
string message = string.Format("Record doesn't exists for Id {0}", id);
throw new InvalidOperationException(message, ex);
}
即使此异常不提供堆栈跟踪以外的更多相关信息,我是否应该维护内部异常?像上面的代码或;
我应该忽略异常并抛出我需要的东西吗?像这样throw new InvalidOperationException(message);
答案 0 :(得分:1)
您提出的问题取决于执行的操作。如果我是你,我会尽可能地保持内部异常。从上面的示例中,您可能不需要Inner异常。
但是让我们来看看这个场景
public class EmployeeDAO
{
public void EmployeeInsert(Employee emp)
{
try
{
//Insert a Employee
}
catch (Exception ex)
{
string message = string.Format("Record doesn't exists for Id {0}", id);
throw new Exception(message, ex);
}
}
}
在上面的内容中,如果你抓住并重新抛出如图所示,你就会失去内部异常。内部异常将包含有用的信息,如连接问题或命令超时或任何类型的东西。
答案 1 :(得分:0)
对上述内容使用预先存在的异常类型可能很难看,因为没有通用的方法来区分InvalidOperationException
Single
引发InvalidOperationException
因为匹配记录的数量不完全相同来自InvalidOperationException
,因为一些完全不同的原因而被抛出。如果Single
由于某种意外原因而被抛出,并且您只是报告异常,就好像预期的那样,那么故障排除可能很困难。另一方面,如果你确实保留了异常,那么客户对它的处理方式并不完全清楚。
或许,即使基于异常消息做出决策通常很难看,但在检查与基础异常相关联的消息并在消息符合期望的情况下抑制内部异常的包含可能会有一些好处。这样的使用可能会使代码在InvalidOperationException
方法的变化方面有些脆弱,但是在单个方法抛出具有预期消息的异常的情况下以及在某些情况下的情况下都会提供更好的行为出于意外原因抛出Single
。这两个“胜利”可能足以克服这样一个事实:{{1}}的更改可能会导致代码不必要地开始包括应该被视为预期场景的内部异常。