왜 저는 캐치 없이 시도만 하거나 마지막으로 글을 쓸 수 없습니까?

왜 저는 캐치 없이 시도만 하거나 마지막으로 글을 쓸 수 없습니까?

닫혔습니다. 이 질문은.여론에 입각한현재 답변을 수락하고 있지 않습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트합니다.

5년 전에 문을 닫았습니다.

이 질문을 개선합니다.

때때로 저는 이것을 하고 다른 사람들도 그것을 하는 것을 보았습니다.

VB:

Try
    DontWannaCatchIt()
Catch
End Try

C#:

try 
{ 
    DontWannaCatchIt();
} 
catch {}

저는 제가 기대하는 모든 중요한 예외를 포착하고 그것에 대해 무언가를 해야 한다는 것을 알고 있습니다. 하지만 때때로 그것은 중요하지 않습니다. 아니면 제가 잘못하고 있는 것일까요?

이것은 의 사용입니까?try정확하지 이상의 . 그리고 적어도 하나의 요구 사항catch또는finally그것의 표시를 차단합니까?

업데이트:

이제 그 이유를 이해했습니다. 그리고 적어도 빈 캐치 블록에 대해 코멘트를 해야 다른 사람들이 빈 이유를 이해할 수 있습니다.저도 제가 기대하는 예외만 잡아야 합니다.

다행히도 저는 VB로 코딩하고 있어서 한 번의 캐치로 작성할 수 있습니다.

Catch ex As Exception When TypeOf ex Is IOException _
                    OrElse TypeOf ex Is ArgumentException _
                    OrElse TypeOf ex Is NotSupportedException _
                    OrElse TypeOf ex Is SecurityException _
                    OrElse TypeOf ex Is UnauthorizedAccessException
    'I don't actually care.
End Try

잡기 싫다면, 왜 당신은 그것을 사용합니까?try애초에?

A try은 어떤 수 하며, 진은당무수잘있믿것의다는는을미고하그고리다, 술고신못될이언가가▁statement▁means고그▁something리.catch당신은 잘못되는 것을 적절하게 처리할 수 있다고 말합니다.

그래서 당신의 예상으로는:

try
{
    //Something that can go wrong
}
catch
{
    //An empty catch means I can handle whatever goes wrong. If a meteorite hits the
    //datacenter, I can handle it.
}

이는 발생하는 모든 예외를 삼킵니다.당신은 당신의 코드가 잘못되는 것은 무엇이든 우아하게 처리할 수 있다는 자신감이 있습니까?

(자신과 유지보수 프로그래머의 건전성을 위해) 최선의 방법은 다음과 같이 우아하게 처리할 수 있음을 명시하는 것입니다.

try
{
    //Something that could throw MeteoriteHitDatacenterException
}
catch (MeteoriteHitDatacenterException ex)
{
    //Please log when you're just catching something. Especially if the catch statement has side effects. Trust me.
    ErrorLog.Log(ex, "Just logging so that I have something to check later on if this happens.")

}

아니요, 모든 중요한 예외를 포착해서는 안 됩니다.I/O 오류와 같이 관심 없는 예외를 포착하고 무시해도 무방합니다. I/O 오류를 수정할 수 있는 방법이 없고 사용자에게 보고하는 것이 번거롭지 않다면 말입니다.

은 하만다음같예허합니다용야해와 같은 를 둘 가 있습니다.StackOverflowException그리고.OutOfMemoryException전파하다아니면, 더 일반적으로,NullReferenceException이러한 예외는 일반적으로 예상하지 못했거나 복구할 수 없으며 복구해서는 안 되며 억제해서는 안 되는 오류입니다.

예외를 무시하려면 특정 예외에 대한 코드에 빈 캐치 블록을 명시적으로 작성하는 것이 좋습니다.이렇게 하면 무시하는 예외가 정확히 무엇인지 알 수 있습니다.예외를 매우 올바르게 무시하는 것은 옵트 인 절차이지 옵트 아웃 절차가 아닙니다.특정 유형을 무시하지 않도록 재정의할 수 있는 "모든 예외 무시" 기능은 매우 나쁜 언어 기능입니다.

어떤 유형의 예외가 중요하고 포착되어서는 안 되는지 어떻게 알 수 있습니까?만약 당신이 모르는 예외가 있다면요?익숙하지 않은 중요한 오류를 억제하지 않을 것이라는 것을 어떻게 알 수 있습니까?

try
{
}
// I don't care about exceptions.
catch
{
}
// Okay, well, except for system errors like out of memory or stack overflow.
// I need to let those propagate.
catch (SystemException exception)
{
    // Unless this is an I/O exception, which I don't care about.
    if (exception is IOException)
    {
        // Ignore.
    }
    else
    {
        throw;
    }
}
// Or lock recursion exceptions, whatever those are... Probably shouldn't hide those.
catch (LockRecursionException exception)
{
    throw;
}
// Or, uh, what else? What am I missing?
catch (???)
{
}

캐치가 없거나 최종적으로 유효하지 않습니다.빈 캐치 또는 마지막으로 유효합니다.빈 캐치는 예외에 신경 쓰지 않고, 그저 무언가를 하려고 노력하고, 그것이 효과가 없어도 상관없고, 그저 계속하고 싶다는 것을 의미합니다.예를 들어 정리 기능에 유용합니다.

또한 오류에 대한 작업을 수행할 필요가 없는 경우 프로그램에서 무시할 수 있는 예외 유형을 지정해야 합니다.

모든 예외를 무시해야 한다면 try/catch를 이런 식으로 사용할 수 없는 이유를 알 수 없습니다.

보통은 실수입니다.예외는 예외적인 행동을 나타냅니다. 예외가 발생하면 무언가 잘못되었다는 것을 의미합니다.그래서 아무 문제가 없는 것처럼 정상적인 프로그램 흐름을 계속하는 것은 오류를 숨기는 방법, 즉 부정의 한 형태입니다.대신 코드가 예외적인 경우를 어떻게 처리해야 하는지 생각하고 코드를 작성합니다.은폐했기 때문에 전파되는 오류는 즉시 나타나는 오류보다 디버깅하기가 훨씬 어렵습니다.

대부분의 개발자들에게 나쁜 관행으로 여겨지기 때문에 당신이 하기가 쉽지 않습니다.

가 나에누다음본문메호어될추까요떻게의 요?DontWannaCatchIt()잡을 가치가 있는 예외를 던지지만 빈 캐치 블록에 삼켜지는 건가요?만약 여러분이 실제로 잡고 싶지만 그 당시에 깨닫지 못했던 몇 가지 예외가 있다면 어떨까요?

반드시 이 작업을 수행해야 하는 경우 발생할 예외 유형을 최대한 구체적으로 지정하십시오.그렇지 않은 경우 예외를 기록하는 것이 옵션일 수 있습니다.

오류가 존재하고, 발생했으며, 어딘가로 이동해야 합니다.정상적인 코드 흐름이 중단되었으므로 팬을 청소해야 합니다.

캐치 블록 없음 = 불확실한 상태입니다.코드는 어디로 가야 합니까?어떻게 해야 할까요?

빈 캐치 블록 = 오류를 무시하여 처리했습니다.

참고: VBA에 잘못된 "On Error Continue"가 있습니다.

제가 들은 이유는 어떤 이유로든 시도가 실패할 경우 오류 응답을 제어하는 것이 프레임워크에 노란색 화면이나 오류 500과 같은 것을 제어하는 것보다 훨씬 낫다는 것입니다.

만약 당신이 시도로 코드만 쓴다면요?

try
{
   int j =0;
   5/j;
}

이것은 쓰는 것과 같습니다.

 int j =0;
   5/j;

그래서 쓰기 시도는 말이 되지 않습니다, 그것은 단지 당신의 행의 수를 증가시킬 뿐입니다.

이제 빈 캐치로 try를 작성하거나 마지막으로 런타임에 다르게 동작하도록 명시적으로 지시하는 것입니다.

그래서 빈 시도 블록이 불가능하다고 생각하는 이유입니다.

네, 그것은 틀렸습니다.같습니다gotoKLoc 100개당 1개는 괜찮지만, 만약 당신이 이것들이 많이 필요하다면, 당신은 그것을 잘못하고 있는 것입니다.

아무런 반응 없이 예외를 삼키는 것은 오류 처리에서 더 나쁜 것 중 하나이며, 최소한 명시적이어야 합니다.

try  
{      
   DontWannaCatchIt(); 
}  
catch 
{
    // This exception is ignored based on Spec Ref. 7.2.a,
    // the user gets a failure report from the actual results, 
    // and diagnostic details are available in the event log (as for every exception)
} 

---

좀 더 자세히 살펴보면 다음과 같습니다.

오류 처리는 한 측면입니다. 일부 상황에서는 오류를 던져 콜 스택 위로 전파해야 합니다(예: 파일 복사, 복사 실패).

다른 컨텍스트에서 동일한 코드를 호출하면 오류를 추적해야 하지만 작업을 계속해야 할 수 있습니다(예: 실패한 파일을 나타내는 로그가 포함된 100개의 파일 복사).

이 경우에도 빈 캐치 핸들러는 틀립니다.

대부분의 언어에서는 루프 내에서 try+catch를 시도하고 catch 핸들러에 로그를 작성하는 것 외에 다른 직접적인 구현은 없습니다. (그러나 mroe 유연한 메커니즘을 구축할 수 있습니다. 메시지를 던지거나 저장할 수 있는 호출별 스레드 핸들러가 있어야 합니다.)그러나 디버깅 도구와의 상호 작용은 직접적인 언어 지원 없이는 어려움을 겪습니다.)

---

현명한 사용 사례는 다음을 구현하는 것입니다.TryX()a부터X()하지만 그것은 문제의 예외를 반환해야 합니다.

언급URL : https://stackoverflow.com/questions/4540155/why-cant-i-write-just-a-try-with-no-catch-or-finally