try-catch块具有返回类型

如果我有一个返回某些东西的方法,比如

public DataTable ReturnSomething()
{
   try
   {  
      //logic here
     return ds.Tables[0];
   }
   catch (Exception e)
   {
      ErrorString=e.Message;
   }
}

这会产生编译器错误,显然是因为catch{}块不返回任何内容.

所以当我有返回值的方法时,我不使用try-catch块,这是一种不好的做法.如果有错误,我想将错误字符串设置为该错误.但是我还需要一个返回值.建议吗？

1> Simon..：

---

将您的返回值存储在一个临时变量中,如下所示:

public DataTable ReturnSomething()
{
    DataTable returnValue = null;

    try
    {
        //logic here
        returnValue = ds.Tables[0]; 
    }
    catch (Exception e)
    {
        ErrorString=e.Message;
    }

    return returnValue;
}

---

像其他人已经注意到的那样,你应该考虑抛出异常而不是设置ErrorString.如果您希望使用自己的消息进行异常,则应抛出一个新异常,并将原始异常作为内部异常.抛出新的ArgumentException("我的消息",e);

2> Manrico Cora..：

---

您应该在catch块中引发/抛出异常并在调用方法中处理它.

public void invokeFaultyCode()
{
    try
    {
        DataTable dt = ReturnSomething();
    }
    catch(Exception e)
    {
        // Print the error message, cleanup, whatever
    }    
}
public DataTable ReturnSomething() throws Exception
{
   try
   {  
      //logic here
     return ds.Tables[0];
   }
   catch (Exception e)
   {
      ErrorString=e.Message;
      throw;
   }
}

PS:很抱歉任何语法错误,我对C#有点生疏.

---

你可能只想扔掉,因为throw e会改变异常堆栈.

---

请注意; 将`throws`附加到方法上是一种在.NET中不存在的Java概念.

3> Bryan Sebast..：

---

你应该用try catch来包装调用者...在被调用的例程中发生的任何异常都会冒出来给调用者,你可以在那里捕获它们.

就个人而言,我认为在这个例程中有一个try catch是不合适的,因为你应该让调用者处理异常.

对于我的例子,这将编码如下......

private void DoSomething() {
    try {
        DataTable dt = ReturnSomething();
    }
    catch (Exception ex) {
    }    
}

public DataTable ReturnSomething() {
    DataTable dt = new DataTable();

    // logic here
    return dt;
}

4> Chris Ammerm..：

---

ErrorString变量看起来像一个错误代码变量.建议的做法是使用异常在必要时直接传递错误信息,而不是将内容存储到错误代码中.

你正在使用ErrorString做同样的事情,就像你只是让调用者捕获异常一样:从方法本身中删除响应错误的责任.这是一个很好的目标.但是使用错误字符串并不能获得任何使用异常的功能.事实上,你以这种方式失去了信息.可能发生任何类型的错误,并且许多错误都与它们相关联,并且具有自己的特殊属性来保存有关失败的上下文信息.只需将消息存储在String中,就会丢失此信息.

因此,除非您的目标是专门隐藏调用者发生的错误类型,否则您只能通过让异常通过来获得.

另一件需要考虑的事情是这是否真的是一个错误场景.如果是,那么你的调用方法几乎不会关心返回值.在这种情况下,您只需让异常进行而不返回任何内容就无需担心.如果它不是一个真正的错误场景,并且调用者只是继续并做其他事情,那么,这是由调用者决定的,对吧？通过返回错误字符串和虚拟DataTable或null来获取仍然没有多少好处,而不是抛出所有上下文失败信息的异常.