예외를 잡았습니다!!자 이제는 뭐죠?

예외를 잡았습니다!!자 이제는 뭐죠?

저는 트라이캐치 블록을 사용하기 시작했지만(조금 늦었지만, 알고 있습니다!), 일단 예외를 잡은 후에는 어떻게 해야 할지 모르겠습니다.어떻게 해야 하나?

Try
    connection.Open()
    Dim sqlCmd As New SqlCommand("do some SQL", connection)
    Dim sqlDa As New SqlDataAdapter(sqlCmd)
    sqlDa.Fill(dt)
Catch ex As SQLException
    ' Ahhhh, what to do now!!!?
Finally
    connection.Close()
End Try

예외 처리에 대한 경험칙--만약 당신이 그것을 어떻게 해야 할지 모른다면, 그것을 잡지 마세요.

예외 처리에 대한 경험칙에 따라 - 마지막 책임 있는 순간에 예외를 처리합니다.이게 마지막 책임감 있는 순간인지 모른다면 그렇지 않습니다.

무엇을 하고 싶습니까?그것은 전적으로 당신의 애플리케이션에 달려 있습니다.

다시 시도하게 할 수도 있고, 화면에 메시지 상자를 표시할 수도 있고, 로그에 쓸 수도 있습니다. 가능성은 무한합니다.

개발자로서 가능한 모든 오류를 예측할 수는 없습니다.오류를 해결하는 방법을 모르는 경우에도 일반 캐치 코드를 사용하는 것이 좋습니다.데이터베이스에 저장하면 50개의 데이터베이스 오류 중 하나가 발생할 수 있으며 모든 오류를 처리하기 위한 코드를 작성할 수 없습니다.

프로그램이 단순히 중단되지 않도록 일반 캐치를 넣어야 하며, 경우에 따라 오류를 표시하고 다른 오류를 허용하는 것으로 충분합니다.원인이 '디스크가 꽉 찼습니다'라고 가정해 보십시오.당신은 그저 예외를 인쇄하고 사용자가 다시 시도하게 할 수 있습니다. 사용자는 무엇을 해야 할지 알고 스스로 문제를 해결할 수 있습니다.

이것이 제가 어떻게 해야 할지 모르면 처리하지 않는다는 의견에 동의하지 않는 이유입니다."이 프로그램이 불법 작업을 수행하여 종료됩니다."보다 훨씬 낫기 때문에 '오류'라는 메시지 상자를 표시하기 위해서라도 항상 처리해야 합니다.

비즈니스 논리에 따라 다르지만 다음 중 하나 이상을 수행할 수 있습니다.

• 트랜잭션 롤백
• 오류 기록
• 모든 사용자에게 응용프로그램 알림
• 작업 재시도
• 예외를 되돌립니다.

위 중 하나보다 먼저 예외를 처리할 수 있는 유형인지 확인할 수도 있습니다.

VB.NET 예외 처리에 대한 좋은 기사는 Rajesh VS의 VB.NET 예외 처리입니다.

어떻게 해야 할지 모르면 잡지 말라는 권고가 많이 보입니다.그것은 일종의 옳은 것입니다.예외를 잡아야 하지만 이 수준에서는 아닐 수도 있습니다.예를 들어 코드를 사용하면 다음과 같이 쓸 수 있습니다.

Using connection As New SqlConnection("connection string here"), _
      sqlCmd As New SqlCommand("do some SQL", connection), _
      sqlDa As New SqlDataAdapter(sqlCmd)

    sqlDa.Fill(dt)
End Using

Try/Catch/Finally, 열려 있거나 닫히지 않습니다..Fill() 기능은 필요한 경우 연결을 여는 것으로 문서화되며 Using 블록은 예외가 발생하더라도 올바르게 닫혔는지 확인합니다.

이렇게 하면 UI 또는 비즈니스 코드에서 바로 여기 쿼리 자체가 아니라 쿼리가 실행되는 함수를 호출하는 등 더 높은 수준의 예외를 자유롭게 파악할 수 있습니다.이 상위 레벨 코드는 진행 방법, 로깅이 수행되어야 하는 사항 또는 사용자에게 더 나은 오류 메시지를 표시할 수 있는 훨씬 더 나은 위치에 있습니다.

사실, 예외가 코드에서 "거품"이 되는 것은 이러한 기능 때문에 매우 가치가 있습니다.예외가 발생한 곳에서 항상 발견되는 경우 예외는 vb의 이전 "On Error Got to X" 구문 이상의 가치를 추가하지 않습니다.

그것은 무엇이냐에 달려 있습니다.SQL정말 그렇습니다. 가뭔?

• 사용자가 했습니까?계정이나 메시지를 만들 수 있습니다. 그런 다음 사용자에게 잘못된 정보를 알려야 합니다.
• 응용 프로그램이 자연스럽게 작동합니까?통나무 청소 같은 거요?치명적인가요?신청을 계속할 수 있습니까?그것은 무시할 수 있는 것입니까? 아마도 재시도 될 것입니까?관리자를 발표해야 합니까?

이러한 질문부터 시작하여, 일반적으로 예외를 처리하는 방법에 대한 답변으로 이어집니다.

오류(API에서 발생할 수 있다고 함)가 발생할 것으로 예상되고 이를 처리할 수 있는 경우(예외가 발생할 경우 취해야 할 분명한 단계가 있음)가 아니라면 많은 소음과 함께 충돌하고 싶을 것입니다.사용자가 보기 전에 버그를 수정할 수 있도록 테스트/디버깅 중에 이 문제가 발생해야 합니다!

물론, 논평가들이 지적했듯이, 사용자는 이 모든 소음을 실제로 봐서는 안 됩니다.고수준try/catch또는 다른 방법(EMLA, .net web projects에서 들은 바 있음)을 사용하여 사용자에게 멋진 오류 메시지를 표시할 수 있습니다.뭔가 잘못됐어요!도대체 무엇을 하려고 했습니까?") 제출 버튼을 사용하여...

그래서 기본적으로, 제 요점은 다음과 같습니다.처리 방법을 모르는 오류를 발견하지 마십시오!(고급 핸들러 제외).가능한 한 많은 정보를 가지고 일찍 충돌합니다.따라서 디버깅을 위해 가능한 경우 통화 스택 및 기타 중요 정보를 기록해야 합니다.

어떻게 반응해야 할지 모르면 예외를 범하지 마십시오.

대신 처리할 수 있는 가능성이 있고 이후에 실행을 계속할 수 있는 방법을 알고 있는 곳에서 잡으십시오.

한 가지 주의할 점은 시도/캐치를 사용하고 싶은 섹션에서는 Dim 문을 시도 블록 밖으로 이동해야 한다는 것입니다.블록 내에서 값을 할당할 수 있지만 시도 블록 내에서 정의하는 경우 해당 시점에서 범위를 벗어나므로 캐치 섹션 내에서 변수에 액세스할 수 없습니다.

가능하면 오류를 수정하는 것을 포함하여 캐치 블록에 대한 제 표준 관행은 오류를 유발한 섹션과 관련된 주요 변수에 대한 정보를 사용하는 로깅 메커니즘에 쓰는 것입니다.필요하지는 않지만 디버깅 문제에 도움이 되는 경우가 많습니다.

저는 당신에게 예외를 어떻게 해야 할지 모른다면, 그것을 잡지 말라고 제안하고 싶습니다.너무 자주, 코더들은 예외를 포착하고 그것들을 통째로 삼킵니다.

catch (Exception ex)
{
  /* I don't know what to do.. *gulp!* */
}

분명히 이것은 좋지 않습니다. 왜냐하면 나쁜 일들이 일어나고 있고 어떤 조치도 취해지지 않기 때문입니다.조치 가능한 예외만 포착!

즉, 우아한 오류 처리가 중요합니다.앱이 중단되는 것을 원하지 않습니다. 그렇죠?ELMAH는 웹 응용 프로그램에 유용할 수 있으며, WinForms 또는 XAML 데스크톱 응용 프로그램에 대해 글로벌 예외 처리기를 설정하는 것이 매우 쉽습니다.

이 모든 것을 종합하면, 이 전략이 유용할 수 있습니다. 1. 발생할 수 있는 특정 예외(DivideByZeroException, SQLException 등)를 포착하고 일반적인 catch-all Exception에서 벗어나십시오. 2. 예외를 처리한 후 다시 발생시킵니다. 예를 들어,

catch (SQLException ex)
{
  /* TODO: Log the error somewhere other than the database... */
  throw; // Rethrow while preserving the stack trace.
}

SQL Exception으로 실제로 무엇을 할 수 있습니까?데이터베이스 연결이 사라졌습니까?잘못된 질문이었나요?여러분은 아마도 그것에 대한 모든 처리 논리를 추가하고 싶지 않을 것이고, 게다가 그것이 여러분이 예상하지 못했던 것이라면 어떨까요?따라서 가능하면 예외를 처리하고, 문제가 해결되었는지 확신할 수 없는 한 다시 제기하고, 글로벌 수준에서 우아하게 처리합니다(예: "뭔가 잘못되었지만 작업을 계속할 수 있을 수도 있습니다"와 같은 메시지를 표시합니다).상세정보 : '[ex.메시지]'.중단 또는 재시도?")

HTH!

존 손더스, 정정해 주셔서 감사합니다.

첫째, 응용 프로그램에서 예외를 처리할 수 있는 방법이 없다면 애초에 예외를 포착해서는 안 됩니다(로그는 예외 이벤트 처리기를 통해 탐지하지 않고 수행할 수 있음)

당신이 할 수 있는 일이 있다면 그렇게 하세요.예를 들어 트랜잭션을 롤백하고 사용자에게 실패했다고 보고합니다.응용 프로그램에 따라 다릅니다.

참고로, 당신은 최종 진술을 하기 위해 캐치를 사용할 필요가 없습니다.

때때로 사람들은 더 친절한 새로운 예외를 던지고 원래의 예외를 내부의 예외로 추가합니다.

오류를 파일에 기록하거나 운영자에게 전자 메일을 보내는 데 사용되는 경우가 많습니다.

때때로, 특히 SQL의 경우, 키가 중복된다는 의미일 수 있습니다. 예를 들어 이미 가져온 다른 사용자 이름을 선택하십시오. 모든 사용자 이름은 애플리케이션에 따라 다릅니다.

예외가 발생했음을 기록하고 사용자에게 요청을 완료할 수 없음을 알립니다.이는 사용자가 수행하려는 작업을 완료하기 위해 이 SQL 요청이 필요하다고 가정합니다.

그것은 전적으로 맥락에 달려 있습니다.가능한 옵션에는 "데이터베이스의 데이터 대신 기본 데이터 사용" 및 "사용자에게 오류 메시지 표시"가 있습니다.

아무것도 하기 싫다면 언제든지 시도/잡기/마지막으로 하는 것이 아니라 시도/마지막으로 하는 것이 좋습니다.

응용 프로그램 유형에 따라 글로벌 로깅 처리기(예: ASP.NET 응용 프로그램의 경우 'Application_Error') 또는 사전 빌드된 오픈 소스 또는 MSFT 제공 예외 처리 프레임워크를 사용하는 것을 고려합니다.

Enterprise Library 5.0의 일부로 예외 처리 응용 프로그램 블록을 사용하는 것이 좋습니다.

로깅을 제외하고, 예외에 대해 의미 있는 작업을 수행할 필요가 없는 한 예외를 명시적으로 파악할 필요가 없다는 점에 동의합니다.그리고 최악의 실수는 스택 추적이 엉망이 될 때 '캐치'했다가 다시 '던지는' 것입니다.

글쎄요, 그것은 주로 여러분이 애플리케이션으로 돈을 벌고 있는지 아닌지에 달려 있습니다.제 경험에 따르면, 아무도 (애플리케이션에 돈을 지불한 사람은) 고장이 나고 닫히는 것을 좋아하지 않으며, 대신 오류에 대한 짧고 설명적인 메시지와 수정된 데이터를 저장/내보낼 수 있는 두 번째 기회를 선호합니다.IMO의 가장 좋은 방법은 I/O 작업, 네트워킹 관련 작업 등과 같이 사용자가 통제할 수 없는 문제를 일으킬 수 있는 모든 것을 파악하여 사용자에게 관련 메시지를 표시하는 것입니다.로직 관련 오류로 인해 예외가 발생한 경우 실제 오류를 찾아 수정하는 데 도움이 되므로 이를 감지하지 않는 것이 좋습니다.

이게 도움이 되길 바랍니다.

언급URL : https://stackoverflow.com/questions/2599680/ive-caught-an-exception-now-what