내 응용 프로그램이 기대하지 않는 모든 조건에 대해 예외가 생성되었습니다. UserNameNotValidException, PasswordNotCorrectException등
그러나 나는 그러한 조건에 대해 예외를 만들지 말아야한다고 들었습니다. 내 UML에서 주 흐름에 대한 예외는 예외이므로 왜 예외가 아니어야합니까?
예외를 만드는 지침이나 모범 사례가 있습니까?
답변
내 개인적인 지침은 : 현재 코드 블록의 기본 가정이 잘못된 것으로 판명되면 예외가 발생합니다.
예제 1 : 임의의 클래스를 검사하고 해당 클래스가 List <>에서 상속되면 true를 반환하는 함수가 있다고 가정하십시오. 이 함수는 “이 개체는 List의 자손입니까?”라는 질문을합니다. 이 함수는 연산에 회색 영역이 없기 때문에 예외를 발생시키지 않아야합니다. 모든 단일 클래스는 List <>에서 상속되거나 상속되지 않으므로 항상 “yes”또는 “no”입니다.
예제 2 : List <>를 검사하고 길이가 50보다 크면 true를 반환하고 길이가 작 으면 false를 반환하는 다른 함수가 있다고 가정 해보십시오. 이 함수는 “이 목록에 50 개가 넘는 항목이 있습니까?”라는 질문을합니다. 그러나이 질문은 가정합니다. 주어진 대상이 목록이라고 가정합니다. 내가 NULL을 건네면 그 가정은 거짓입니다. 이 경우 함수가 true 또는 false를 반환 하면 자체 규칙을 위반하는 것입니다. 이 함수는 아무 것도 반환 할 수 없으며 질문에 올바르게 답변했다고 주장 할 수 없습니다 . 따라서 반환되지 않습니다-예외가 발생합니다.
이것은 “로드 된 질문” 논리적 오류 와 비슷합니다 . 모든 기능은 질문을합니다. 입력이 주어지면 그 질문에 오류가 생기면 예외를 던집니다. 이 줄은 void를 반환하는 함수를 사용하여 그리기가 더 어렵지만 결론은 입력에 대한 함수의 가정이 위반되면 정상적으로 반환하는 대신 예외를 발생시키는 것입니다.
이 방정식의 다른 측면은 다음과 같습니다. 함수에서 예외를 자주 발생시키는 경우 가정을 구체화해야합니다.
답변
그것들은 정상적으로 일어날 일이기 때문입니다. 제어 흐름 메커니즘은 예외입니다. 사용자는 종종 암호를 잘못받습니다. 예외가 아닙니다. 예외는 정말 드물고 UserHasDiedAtKeyboard유형 상황 이어야합니다 .
답변
저의 작은 가이드 라인은 “Code complete”라는 훌륭한 책에 크게 영향을받습니다.
- 무시해서는 안되는 사항에 대해 알리려면 예외를 사용하십시오.
- 오류를 로컬에서 처리 할 수있는 경우 예외를 사용하지 마십시오
- 예외가 나머지 루틴과 동일한 추상화 레벨에 있는지 확인하십시오.
- 예외적 인 사항은 예외 입니다.
답변
사용자 이름이 유효하지 않거나 암호가 올바르지 않은 경우 예외가 아닙니다. 이것들은 정상적인 작동 흐름에서 기대해야 할 것입니다. 예외는 정상적인 프로그램 작업의 일부가 아니며 드물다.
편집 : 메소드를 호출하는 것만으로 예외를 throw하는지 알 수 없기 때문에 예외 사용을 좋아하지 않습니다. 따라서 예외를 적절한 방식으로 처리 할 수없는 경우에만 예외를 사용해야합니다 ( “메모리 부족”또는 “컴퓨터가 작동 중”이라고 생각).
답변
일반적으로 예측할 수없는 경우 예외를 사용하는 것이 좋습니다. 데이터베이스 연결, 디스크에 파일이없는 등의 예가 있습니다. 예측할 수있는 시나리오 (예 : 잘못된 비밀번호로 로그인하려는 사용자는 부울을 리턴하고 상황을 정상적으로 처리하는 방법을 알고있는 기능을 사용해야 함)를 사용해야합니다. 누군가가 암호를 잘못 입력하여 예외를 throw하여 갑자기 실행을 끝내고 싶지 않습니다.
답변
다른 사람들은 사용자가 잘못 입력하면 정상적인 흐름으로 잘못된 로그인이 예상되므로 예외를 사용해서는 안된다고 제안합니다. 나는 동의하지 않으며 추론을 얻지 못한다. 파일을 여는 것과 비교해보십시오. 파일이 존재하지 않거나 어떤 이유로 사용할 수없는 경우 프레임 워크에서 예외가 발생합니다. 위의 논리를 사용하는 것은 Microsoft의 실수였습니다. 오류 코드를 반환해야합니다. 파싱, 웹 요청 등에도 동일합니다.
정상적인 흐름의 잘못된 로그인 부분을 고려하지 않습니다. 예외적입니다. 일반적으로 사용자는 올바른 비밀번호를 입력하고 파일이 존재합니다. 예외적 인 경우는 예외적이며 예외를 사용하는 것이 좋습니다. 스택의 n 레벨을 통해 반환 값을 전파하여 코드를 복잡하게 만드는 것은 에너지 낭비이며 코드가 지저분해질 수 있습니다. 가능한 가장 간단한 일을하십시오. 오류 코드를 사용하여 조기에 최적화하지 마십시오. 정의에 따른 예외적 인 일은 거의 발생하지 않으며 예외를 발생시키지 않으면 비용이 발생하지 않습니다.
답변
예를 들어, 잘못된 암호를 제공하는 사용자가있는 경우 예외는 다소 비용이 많이 드는 영향입니다. 일반적으로 실패 플래그 나 다른 잘못된 표시기를 다시 전달하는 것이 좋습니다.
이는 예외 처리 방식, 잘못된 입력 오류 및 고유 한 중요 중지 항목은 예외 여야하지만 로그인 정보는 실패하지 않기 때문입니다.
