리턴 유형이있는 트러블 캐치 블록

StackOverflow https://stackoverflow.com/questions/602699

  •  03-07-2019
  •  | 
  •  

문제

내가 무언가를 반환하는 메소드가 있다면

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

이것은 컴파일러 오류를 생성합니다 catch{} 블록은 아무것도 반환하지 않습니다.

따라서 반환 값이있는 메소드가있을 때는 Try-Catch 블록을 사용하지 않습니다. 이는 나쁜 연습입니다. 오류가 있으면 오류 문자열을 해당 오류로 설정하고 싶습니다. 그러나 반환 값도 필요합니다. 조언?

도움이 되었습니까?

해결책

반품 값을 다음과 같은 임시 변수로 저장하십시오.

public DataTable ReturnSomething()
{
    DataTable returnValue = null;

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

    return returnValue;
}

다른 팁

캐치 블록에서 예외를 올리거나 던지고 호출 방법으로 처리해야합니다.

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;
   }
}

추신 : 구문 오류에 대해 죄송합니다. C#에 약간 녹슬 었습니다.

발신자에게 시도 캐치로 포장해야합니다 ... 루틴에서 발생하는 예외는 발신자에게 버블 링되어 거기에서 잡을 수 있습니다.

개인적으로, 나는 발신자가 예외를 처리해야하기 때문에이 루틴에서 시도해 보는 것이 과잉이라고 생각합니다.

내 예를 들어, 이것은 다음과 같이 코딩됩니다 ...

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

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

    // logic here
    return dt;
}

ErrorString 변수는 의심스럽게 오류 코드 변수처럼 보입니다. 권장되는 관행은 예외를 사용하여 오류 정보를 오류 코드에 저장하지 않고 직접 오류 정보를 전달하는 것입니다.

당신은 발신자가 예외를 잡을 때와 마찬가지로 오류가 발생하는 것과 동일한 일을 효과적으로 수행하고 있습니다. 메소드 자체에서 오류에 대한 응답에 대한 책임을 제거합니다. 이것은 좋은 목표입니다. 그러나 오류 문자열을 사용한다고해서 예외를 사용하는 동안 아무것도 얻지 못합니다. 사실, 당신은 이런 식으로 정보를 잃습니다. 발생할 수있는 여러 가지 유형의 오류가 있으며, 많은 오류가 있으며, 많은 오류가 그들과 관련된 특별한 예외를 가지고 있으며, 실패에 대한 상황에 대한 정보를 보유 할 수있는 특수 속성이 있습니다. 메시지를 문자열에 저장하면이 정보를 잃어 버립니다.

따라서 목표가 특히 발신자로부터 발생하는 오류 유형을 숨기는 것이 아니라면 예외를 통해서만 얻을 수 있습니다.

고려해야 할 또 다른 것은 이것이 진정으로 오류 시나리오인지 여부입니다. 그렇다면 호출 방법이 반환 값이 무엇인지 전혀 관리하지 않을 가능성은 거의 없습니다. 어떤 경우에는 예외를 놓아주고 아무것도 반환하지 않으면 걱정할 것이 없습니다. 실제로 오류 시나리오가 아니고 발신자가 계속해서 다른 일을 할 것입니다. 발신자가 결정해야 할 것입니다. 오류 문자열과 더미 데이터 가능 또는 널을 반환하여 모든 상황에 맞는 실패 정보로 예외를 던지면 여전히 얻을 수있는 이점이 여전히 많지 않습니다.

"예외 경로를 던지지 말라"(반드시 추천 할 필요는 없음)로 향하는 경우 MS 사용이 사용하는 TryParse 접근 방식을 따를 수 있습니다.

같은 것 :

private string FillDataTable(out DataTable results)
{

  try
{
  results = new DataTable(); //something like this;
  return String.Empty;
}
catch (Exception ex)
{
  results = null;
 return ex.Message;

}

}

응용 프로그램에 따라 다릅니다. 당신은 돌아올 수 있습니다 null, 빈 DataTable 또는 상황에서 적합한 것은 무엇이든.

나는 당신이 여전히 메시지를 설정할 수 있다고 생각한 다음 NULL 또는 C# 동등한 점을 반환 할 수 있다고 생각합니다.

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

이건 어때 : 

public DataTable ReturnSomething(out string errorString)
{
   errorString = string.Empty;
   DataTable dt = new DataTable();
   try
   {  
      //logic here
     dt = ds.Tables[0];
   }
   catch (Exception e)
   {
      errorString = e.Message;
   }
   return dt;
}

예에서 예외를 제외하고 다시 던지지 않기 때문에 외부 코드는 모든 것이 괜찮다고 가정하므로 유용한 것을 반환해야합니다.

예외를 포착하고 모든 일을해야한다면 괜찮지 만 여전히 오류 케이스라면 방금 innerexception으로 잡힌 것과 다른 예외를 던져야합니다.

코드가 충분히 높은 수준의 통화 스택에서 실행되고 있으며 UI 코드와 혼합되어 있다고 생각합니다. 이것이 사실이라면, 당신은 할 수 있습니다 return null 캐치 블록에서. 그러나 재사용 가능한 코드를 작성하는 경우 UI 조작을 포함하지 않고 통화 스택의 더 높은 수준에서 예외를 처리하도록 리팩터링해야합니다.

You can do it like the sample code below.

public DataTable ReturnSomething(out string OutputDesc)
{
   try
      {
         //logic here
         OutputDesc = string.Format("Your Successful Message Here...");
         return ds.Tables[0];
      }
      catch (Exception e)
      {
         OutputDesc =e.Message;
         return null;
      }

}
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top