try catch-blocks를 잘 사용하십니까?

나는 항상 이것과 씨름하고 있습니다 ... 시도 잡기와 코드 사이의 올바른 균형을 찾으려고 노력합니다. 탭, 괄호 및 예외의 혼란이 핫 감자처럼 콜백에 던져지지 않습니다. 예를 들어, SQLite를 사용하는 지금 개발중인 앱이 있습니다. SQLite 호출을 추상화하는 데이터베이스 인터페이스와 데이터베이스로 들어가거나 나가는 것을 받아들이는 모델이 있습니다. 따라서 SQLite 예외가 발생하면 모델 (이것이라고 불리는 사람)에게 던져 져야합니다. ), 누가 AddRecord / DeleteRecord / whatever를 호출 한 사람에게 전달해야합니다.  

오류 코드를 무시하거나 잊어 버릴 수 있기 때문에 오류 코드를 반환하는 것과 달리 예외의 팬입니다. 그러나 예외는 본질적으로 처리해야합니다 (허가, 즉시 잡을 수 있습니다 ...). 제가 지금 진행하고있는 것보다 더 나은 방법이 있어야합니다.

편집 :  나는 이것을 조금 다르게 표현해야합니다. 나는 다른 유형으로 다시 던지는 것을 이해합니다. 내 질문은 ... 코드를 깨끗하게 유지하는 가장 좋은 방법은 무엇입니까? 그것은 얼마 후 나에게 매우 혼란스럽게 느끼기 시작합니다.

강력한 유형의 언어를 사용하지 않더라도 강력한 타이핑의 관점에서 생각하십시오. 메소드 가 예상 한 유형을 리턴 할 수 없으면 예외가 발생해야합니다.

또한 SQLException을 모델 (또는 더 나쁜 경우 UI)까지 내 던지기보다는 각 계층에서 알려진 예외를 포착하고 해당 계층에 적합한 예외로 랩 / 돌연변이 / 교체해야합니다.

Layer      Handles Exception
----------------------------
UI         DataNotFoundException
Model      DatabaseRetrievalException
DAO        SQLException

이를 통해 각 계층에서 찾고있는 예외 수를 제한하고 체계적인 예외 시스템을 유지 관리 할 수 ​​있습니다.

대부분의 경우 정상적인 경우를 처리하고 예외적 인 경우는 다른 상황에서도 처리 할 수 ​​있기 때문에 예외로 인해보다 명확한 코드를 작성할 수 있습니다.

예외 처리 (캐치) 규칙은 실제로 무언가를 수행 할 수있는 컨텍스트에 의해 수행되어야한다는 것입니다. 그러나 그것은 예외가 있습니다.

예외는 모듈 경계 (특히 계층 경계)에서 발생해야하며,이를 둘러싸더라도 호출자에게 의미가있는 상위 수준 예외를 발생시킵니다. 각 모듈과 계층은 예외와 관련하여 구현 세부 사항을 숨겨야합니다 (힙 모듈은 HeapFull을 발생 시키지만 ArrayIndexOutOfBounds는 절대로 발생하지 않습니다).

귀하의 예에서 상위 계층이 SQLite 예외에 대해 아무것도 할 수 없을 것입니다 (그렇다면 SQLite에 너무 결합되어 데이터 계층을 다른 것으로 전환 할 수 없음). 추가 / 삭제 / 업데이트와 같은 것들이 실패 할 것으로 예상 할 수있는 몇 가지 이유가 있으며, 그 중 일부 (동시 트랜잭션의 호환되지 않는 변경 사항)는 데이터 / 지속성 계층 (무결성 규칙 위반, fi)에서도 복구가 불가능합니다. 지속성 계층은 예외를 모델 계층 용어에서 의미있는 것으로 변환하여 상위 계층이 재 시도 할 것인지 또는 정상적으로 실패 할지를 결정할 수 있습니다.

일반적으로 특정 예외 (예 : IOException) 만 포착해야하며 예외를 발견 한 후 수행해야 할 특정 조치가있는 경우에만 해당됩니다.

그렇지 않으면, 예외를 노출시켜 처리하고 처리 할 수 ​​있도록하는 것이 가장 좋습니다. 어떤 사람들은 이것을 빠른 실패라고 부릅니다.

아래에서 버블 링 된 처리되지 않은 예외를 포착하려면 응용 프로그램 루트에 일종의 처리기가 있어야합니다. 이를 통해 예외를 적절한 방식으로 제시,보고 또는 관리 할 수 ​​있습니다.

예외 랩핑은 분산 시스템에서 예외를 발생시켜야하고 클라이언트에 서버 측 결함에 대한 정의가없는 경우에 유용합니다.

스택 클래스를 작성한다고 가정하십시오. 클래스에 예외 처리 코드를 넣지 않으면 다음과 같은 예외가 발생할 수 있습니다.

1. ArrayIndexError-사용자가 빈 스택에서 팝을 시도 할 때 발생합니다.
2. NullPtrException-구현의 버그로 인해 null 참조를 참조하려고했기 때문에 발생

예외 래핑에 대한 간단한 접근 방식은 이러한 두 예외를 모두 StackError 예외 클래스로 래핑하기로 결정할 수 있습니다. 그러나 이것은 예외를 래핑하는 요점을 실제로 놓칩니다. 개체가 하위 수준 예외를 throw하면 개체가 손상되었음을 의미합니다. 그러나 이것이 허용되는 한 가지 경우가 있습니다 : 객체가 실제로 파손 된 경우.

예외를 줄 바꿈하는 것은 개체가 정상적인 오류에 대해 적절한 예외를 제공해야한다는 것입니다. 빈 스택에서 팝할 때 스택은 ArrayIndexError가 아닌 StackEmpty를 발생시켜야합니다. 의도는 없는 개체 또는 코드가 파손 된 경우 다른 예외가 발생하지 않도록 할 수 있습니다.

우리가 정말로 피하고 싶은 것은 높은 수준의 객체를 통해 전달 된 낮은 수준의 예외를 포착하는 것입니다. 빈 스택에서 팝할 때 ArrayIndexError를 발생시키는 스택 클래스는 사소한 문제입니다. 실제로 해당 ArrayIndexError를 잡으면 심각한 문제가 있습니다. 낮은 수준의 오류를 전파하는 것은 훨씬 덜 심각한 죄입니다.

이것을 SQLException 예제로 다시 가져 오려면 왜 SQLException이 발생합니까? 한 가지 이유는 잘못된 쿼리를 전달하기 때문입니다. 그러나 데이터 액세스 계층이 잘못된 쿼리를 생성하는 경우 해당 쿼리가 손상됩니다. DataAccessFailure 예외에서 끊어진 부분을 다시 줄이려고 시도해서는 안됩니다.

그러나 데이터베이스 연결이 끊어져서 SQLException이 발생할 수도 있습니다. 그 시점에 대한 나의 전략은 마지막 방어 라인에서 예외를 포착하고 데이터베이스 연결이 끊어지고 종료되었다는 것을 사용자에게보고하는 것입니다. 응용 프로그램이 데이터베이스에 액세스 할 수 없으므로 실제로 수행 할 수있는 작업이 많지 않습니다.

코드가 어떻게 생겼는지 모르겠습니다. 그러나 모든 예외를 맹목적으로 더 높은 수준의 예외로 변환하는 것처럼 들립니다. 비교적 적은 수의 경우에만 그렇게해야합니다. 가장 낮은 수준의 예외는 코드의 버그를 나타냅니다. 잡기와 다시 포장하는 것은 비생산적입니다.