언제 예외 처리 코드 작성을 시작합니까? 언제 로깅 문 작성을 시작합니까?
이 질문을 구체화하기 위해 우리가 log4net 로깅을 사용하는 .NET 플랫폼에 있다고 가정하지만 일반적인 방식으로 자유롭게 대답하십시오.
솔루션 : Windows Forms 프로젝트. 프로젝트 : UI, BusinessRules, DataHandlers
따라서 먼저 Create, Read, Update, Delete와 같은 데이터 조작을 수행하는 DataHandler를 작성하십시오.
그런 다음 비즈니스 규칙을 따르십시오
그런 다음 UI 또는 위의 다른 순열입니다.
기능성에 대한 응용 프로그램을 테스트하십시오.
그리고 다음 코드 및 취급하여 예외 쓰기 시작 마지막으로 당신의 로깅 코드를?
예외 처리 코드를 작성하기에 적합한시기는 언제입니까?
추신 : Clean Code 책에서 try-catch-finally 블록을 먼저 작성하십시오 . 그것은이 질문을하도록 자극했다.
답변:
예외를 일으킬 수있는 것을 호출하는 것을 작성할 때 예외 처리 코드를 작성합니다.
예를 들어, 네트워크로 데이터를 전송하는 것을 작성할 때 연결 시간 종료를 처리하는 코드도 작성해야합니다. 예외는 당신이하는 일과 직접적으로 관련이 있으며, 그 일은 마음에 새롭습니다.
반면, 잘못된 프로토콜 데이터 단위가 발생할 때 예외를 발생시키는 구문 분석기를 작성하는 경우 구문 분석기가 생성하는 예외에 대한 예외 처리 코드 를 작성할 수 없습니다 . ( 물론 파서가 언제 어떻게 예외를 발생시키는 지 보여주기 위해 테스트를 작성하고 있습니다!)
try-catch-finally를 먼저 작성하라는 제안의 이유 는 두 가지입니다. 마지막으로 함수가 생성 / 소비하는 리소스를 정리하고 catch를 작성하는 것은 호출하는 함수가 실패 할 수 있다는 것을 상기시켜줍니다. 그러한 실패를 처리해야합니다 (필요한 경우).
사실 후에 로깅을 추가하는 경향이 있습니다. 그것이 현명한 지 확실하지 않지만 그것은 나를 위해 일한 것입니다. 승인 테스트 등을 시작하고 문제가 발생하기 시작하면 로깅을 추가하여 오류를 추적 할 수 있습니다. (그리고 나는 로그인을 남겨 둡니다.)
내 경험상 처음부터 적절한 오류 처리 및 로깅으로 코드를 작성하지 않으면 시간 압박으로 인해 코드가 작성되지 않습니다. 내가 가장 성공한 개발 노력은 코딩 표준, 오류 처리 방법, 로깅, 기본 아키텍처 및 테스트 도구를 포함한 기본 응용 프로그램 구조를 결정하는 데 소요되는 시간으로 시작되었습니다.
그렇지 않으면 "오류 처리 개선"및 "로깅 시스템 생성"과 같은 버전 2.0에 대한 작업이있는 것을 알 수 있습니다. 이것들은 새로운 기능에 유리하게 삭감 될 것이며, "너무 많은 일"을하기 때문에 생각하지 못한 오류의 경우 모든 버그를 수정합니다. (로깅 시스템이 없기 때문에 시간이 오래 걸립니다.
무엇을하고 있는지에 따라
예외 :
오류가있을 가능성이있는 항목이나 예외가 발생했을 때 예외가 발생하도록 할 수있는 최상위 지점이있는 항목을 작성하는 경우.
성능이 필요하고 오류 가능성이 낮은 것을 작성하는 경우 오류 처리기를 넣을 의미있는 장소가 부족한 경우 테스트에서 오류 처리기가 필요한 것으로 판단되는 경우 오류 처리기를 작성하십시오.
두 경우 모두 오류와 관련이없는 경우 버블 링 (핸들러 없음)을 고려하십시오.
로깅 :
감사 추적이 필요한 경우 먼저 로깅을 작성해야합니다. 오류가 맨 위에 표시되도록하는 경우 로그를 캡처 할 수 있도록 로깅을 제공해야합니다.
이러한 경우를 제외하고는 일반적으로 테스트 / 사용이 필요하다는 것을 입증하는 장소에만 로깅을 추가하고 일반적으로 완료되면 구성 할 수있는 옵션을 만듭니다.
감사 및 예외 처리를 서비스로 구현할 수 있습니다. 응용 프로그램 수준 감사 로깅에는 각 비즈니스 트랜잭션에 대한 상태 데이터가 필요합니다. 비즈니스 또는 트랜잭션 컨텍스트에서 응용 프로그램을 모니터링 할 수 있으려면 서비스 내의 모니터링 인터페이스에서 서비스 호출과 관련된 트랜잭션 상태를 자세히 설명하는 메시지를 보내야합니다. 이를 위해서는 각 서비스가 비즈니스 트랜잭션의 중요한 단계에서 상태 메시지를 보내야합니다. 그런 다음 실시간 뷰어를 구축하여 상태 메시지 (메시지의 의미 (예 : 트랜잭션 ID)를 기반으로 함)를 복합 애플리케이션 내의 서비스와 연관시킬 수 있습니다. 이는 SLA 관리, 결함 추적 및 문제점 판별을위한 비즈니스 트랜잭션에 대한 엔드 투 엔드보기를 제공합니다.
그런 다음 구성에 정의 된 기준에 따라 메시지를 소비하고 기록 할 수있는 상태 머신으로 감사 서비스를 구현할 수 있습니다. 일반 예외 핸들러는 감사 서비스를 사용하여 엔터프라이즈 SOA에서 발생하는 문제의 중앙 집중식보기를 지원하여 예외 기반 모니터링을 지원할 수도 있습니다. 솔루션에서 발생하지 않아야하는 조건은 예외 메시지를 예외 핸들러 로 보내도록 설계되었습니다 .