예외를 잡았습니다 !!

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

---

try catch 블록을 사용하기 시작했습니다 (조금 늦게 알고 있습니다!).하지만 이제 예외를 포착하면 어떻게해야할지 모르겠습니다. 어떻게해야합니까?

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

---

예외 처리에 대한 경험 법칙-어떻게해야할지 모르겠다면 포착하지 마십시오.

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

---

무엇을 하시겠습니까? 전적으로 애플리케이션에 따라 다릅니다.

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

개발자로서 가능한 모든 오류를 예측할 수는 없습니다. 오류를 수정하는 방법을 모르더라도 일반 catch 코드를 포함하는 것이 좋습니다. 데이터베이스에 저장할 수 있으며 50 개의 데이터베이스 오류 중 하나가 발생할 수 있으며 모든 오류를 처리하는 코드를 작성할 수 없습니다.

여러분의 프로그램이 단순히 crash 되지 않도록 일반 캐치를 넣어야합니다 . 어떤 경우에는 단순히 오류를 표시하고 다른 작업을 수행하는 것으로 충분합니다. 원인이 '디스크가 꽉 찼습니다'라고 상상해보십시오. 예외를 인쇄하고 사용자가 다시 시도하도록 할 수 있습니다. 사용자는 무엇을해야하는지 알고 스스로 문제를 해결할 것입니다.

이것이 내가 무엇을 해야할지 모르면 처리하지 않는다는 의견에 동의하지 않는 이유입니다. "오류"라는 메시지 상자를 표시하는 것만으로도 "이 프로그램은 잘못된 연산을 수행하여 종료됩니다"보다 훨씬 낫기 때문에 항상 처리해야합니다.

---

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

• 거래 롤백
• 오류 기록
• 응용 프로그램의 모든 사용자에게 경고
• 작업을 다시 시도하십시오.
• 예외 다시 던지기

또한 예외가 위 중 하나 전에 처리 할 수있는 유형인지 확인할 수도 있습니다.

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

---

나는 당신이 그것을 어떻게해야할지 모른다면 그것을 잡지 말라는 많은 권고를 본다. 그것은 단지 일종의 옳습니다. 예외를 포착해야하지만이 수준에서는 아닐 수도 있습니다. 예를 들어 귀하의 코드를 사용하여 다음과 같이 작성하겠습니다.

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 또는 비즈니스 코드에서 쿼리 자체에서 바로 여기가 아니라 쿼리가 실행되는 함수를 호출합니다. 이 높은 수준의 코드는 진행 방법, 로깅이 필요한 사항에 대한 결정을 내리거나 사용자에게 더 나은 오류 메시지를 표시하는 데 훨씬 더 나은 위치에 있습니다.

사실, 예외가 코드에서 "버블 업 (bubble up)"하는 기능이이를 매우 가치있게 만듭니다. 예외가 발생하는 곳에서 항상 예외를 포착하면 예외가 vb의 이전 "On Error Goto X"구문을 넘어서는 많은 가치를 추가하지 않습니다.

---

sql실제로 무엇을하는지에 달려 있습니다 . 뭔가요?

• 사용자가 했습니까? 계정이나 메시지를 생성 한 다음 사용자에게 문제가 있음을 알려야합니다.
• 응용 프로그램이 자연스럽게 수행합니까? 로그 나 비슷한 것을 정리하는 것과 같은가요? 치명적입니까? 신청을 계속할 수 있습니까? 무시할 수있는 것입니까? 다시 시도 할 수 있습니까? 관리자를 발표해야합니까?

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

---

오류를 예상하고 (API가 발생할 수 있다고 말합니다) 처리 할 수없는 경우 (예외가 발생하는 경우 취할 수있는 분명한 조치가 있음), 많은 소음과 함께 충돌을 원할 것입니다 . 이것은 테스트 / 디버깅 중에 발생해야 사용자가보기 전에 버그를 수정할 수 있습니다!

물론 댓글 작성자가 지적했듯이 사용자는이 모든 소음을 실제로 볼 수 없습니다 . 고급 try/catch또는 다른 방법 (EMLAH, .net 웹 프로젝트의 경우 들었습니다)을 사용하여 사용자에게 멋진 오류 메시지 ( "죄송합니다! 문제가 발생했습니다! 도대체 무엇을하려고 하셨나요?")를 표시하는 데 사용할 수 있습니다. 제출 버튼 ...

그래서 기본적으로 내 요점은 이것이다 : 처리하는 방법을 모르는 오류를 포착하지 마십시오! (고수준 핸들러 제외). 가능한 한 많은 정보와 함께 일찍 충돌하십시오. 이는 디버깅을 위해 가능한 경우 호출 스택 및 기타 중요한 정보를 기록 해야 함을 의미합니다 .

---

이에 대응하는 방법을 모른다면 예외를 포착하지 마십시오.

Catch it instead in a place where you have the possibility to handle it and where you know how to continue execution afterwards.

---

One thing to keep in mind is that in sections where you feel you do want to use a try/catch, you should move your Dim statements out of the try block. You can assign them values inside the block, but if you define them inside the try block, you won't have access to those variables inside the catch section as they will be out of scope at that point.

My standard practice in catch blocks, including trying to remediate the error if possible, is to write out to whatever logging mechanism I am using information about key variables that were involved in the section causing the error. It's not necessary, but I've found it often helps with debugging problems.

---

I'd like to suggest to you that if you do not know what to do with an exception, do not catch it. Too often, coders catch exceptions and just swallow them whole.

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

Clearly this isn't good, because bad things are happening, and no action is being taken. Only catch exceptions that are actionable!

That said, graceful error handling is important. Don't want your app to crash, right? You may find ELMAH useful for web applications, and a global exception handler is pretty easy to set up for WinForms or XAML desktop apps.

Putting all that together, you might find this strategy useful: 1. catch specific exceptions that you know might occur (DivideByZeroException, SQLException, etc.) and steer away from the generic catch-all Exception; 2. re-raise the exception after you handle it. e.g.

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

What can you really do with a SQLException? Did the database connection disappear? Was it a bad query? You probably don't want to add all the handling logic for that, and besides, what if it's something you didn't expect? So just handle the exception if you can, re-raise it unless you're certain it's resolved, and gracefully handle it at a global level (e.g. Show a message like "Something went wrong, but you might be able to continue working. Detailed info: '[ex.Message]'. Abort or Retry?")

HTH!

John Saunders, thanks for the correction.

---

First, if there is no way for your application to handle the exception then you shouldn't catch it in the first place (logging can be done via exception event handlers without catching).

If there is something you can do then do that. For example, roll back the transaction and report it failed to the user. This is going to depend on your application.

---

FYI, you don't have to use the catch to have a finally statement.

Sometimes people throw a new exception that is more firendly and add the original exception as the inner exception.

Often this is used to log the error to a file or send an email to an operator.

Sometimes, especially with SQL, it may just mean a duplicate key which means, for example, please choose another username, that one is already taken - it's all down to your application.

---

I would consider logging that the exception took place and notify the user that you were unable to complete their request. This assumes that this SQL request is necessary to completion of the action the user is attempting to perform.

---

It depends entirely on context. Possible options include "Use default data instead of data from the database" and "Display an error message to the user".

---

If you don't want to do anything with it, you can always just do try/finally rather then try/catch/finally

---

Depending on the type of application, consider either a global logging handler (i.e. 'Application_Error' for ASP.NET applications) or using a pre-built open source or MSFT provided exception handling framework.

The Exception Handling Application Block as part of the Enterprise Library 5.0 is a suggested framework to use.

Aside from logging, I agree that exceptions need not be explicitly caught unless you need to do something meaningful with them. And the worst mistake is just to 'Catch' and then 'Throw' again as this messes the StackTrace up.

---

Well, That depends primarily if you are making money from your application or not. By my experience, nobody (who paid for an application) likes to see it crashing and closing, instead they prefer a short and explanatory message about the error and a second chance to continue whatever they were doing plus a chance to save/export their modified data. IMO a best practice is to catch everything that can cause something wrong out of your control, like I/O operations, networking related tasks, e.t.c. and display a relevant message to the user. In case that an exception is thrown due to a logic related error is better not to catch it since this will help you to find and correct the actual error.

Hope this helps.

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