첫째, 다른 사람들이 언급했듯이 C ++에서는 IMHO 가 명확하게 잘리지 않습니다 .IMHO는 요구 사항과 제약 조건이 다른 언어보다 C ++에서 다소 다양하기 때문에 esp. "유사한"예외 문제가있는 C # 및 Java
std :: stof 예제를 공개하겠습니다.
빈 문자열을 std :: stof에 전달하면 프로그래밍 오류가 아닌 invalid_argument가 발생 함
기본 계약은 내가보기로,이 기능은 부동 소수점으로의 인수 변환을 시도하고 있다는 것입니다 어떤 이렇게하는 실패는 예외로보고됩니다. 두 가지 가능한 예외 는 모두 logic_error프로그래머 오류라는 의미가 아니라 "입력을 부동으로 변환 할 수 없다"는 의미에서 비롯된 것 입니다.
여기에서 logic_error(런타임) 입력이 주어지면 항상 변환하려고하면 오류가 있음을 나타내는 데 a 가 사용된다고 말할 수 있습니다.
참고 :이보기에서 a 는 함수에 동일한 입력이 주어지면 이론적으로 다른 실행에 성공할 runtime_error 수 있는 것으로 간주 될 수 있습니다. (예 : 파일 작업, DB 액세스 등)
추가 참고 : C ++ 정규식 라이브러리 는 여기와 동일하게 분류 될 수 있는 runtime_error경우가 있지만 오류가 발생 하도록 선택했습니다 (잘못된 정규식 패턴).
이것은 IMHO 가 C ++에서 그룹화 logic_하거나 runtime_오류가 퍼지 하고 일반적인 경우 (*)에서 실제로 큰 도움이되지 않는다는 것을 보여줍니다. 특정 오류를 처리 해야하는 경우 두 개보다 낮게 잡을 수 있습니다.
(*) : 즉 코드의 한 조각이 일치하지 않을 것을 말하는 것이 아니다, 그러나 당신은 던져 여부 runtime_나 logic_또는 custom_일도 중요한 것은, 내가 생각하지 정말이다.
stof와 둘 다에 대해 언급하려면 bitset:
두 함수 모두 문자열 을 인수로 사용하며 두 경우 모두 다음과 같습니다.
- 주어진 문자열이 유효한지 여부를 호출자에게 확인하는 것은 사소한 일이 아닙니다 (예 : 최악의 경우 함수 논리를 복제해야합니다.
- 문자열을 "파싱"하는 것은 이미 함수의 책임이므로 문자열을 이미 확인해야하므로 문자열을 균일하게 "사용"하는 오류를보고하는 것이 합리적입니다 (두 경우 모두 예외입니다). .
예외와 함께 자주 나타나는 규칙은 "예외 상황에서만 예외 사용"입니다. 그러나 라이브러리 함수는 어떤 상황이 예외적인지 어떻게 알 수 있습니까?
이 진술에는 IMHO의 두 가지 뿌리가 있습니다.
성능 : 중요한 경로에서 함수가 호출되고 "예외"사례가 예외적 이지 않은 경우, 즉 많은 양의 패스에는 예외가 발생하는 경우 예외 풀림 기계에 대해 매번 지불하는 것이 의미가 없습니다. 및 수 너무 느려.
에러 처리의 소재지 : 함수가 호출되고, 예외가 바로 잡아서 처리하면 에러 핸들링을 더 상세 바와 같이, 그 다음 예외 발생 작은 지점이 존재 와catch 보다 if.
예:
float readOrDefault;
try {
readOrDefault = stof(...);
} catch(std::exception&) {
// discard execption, just use default value
readOrDefault = 3.14f; // 3.14 is the default value if cannot be read
}
TryParsevs. 와 같은 함수가 작동하는 위치는 다음과 같습니다 Parse. 로컬 코드 가 구문 분석 된 문자열이 유효 할 것으로 예상 되는 버전 1 개, 로컬 코드가 실제로 구문 분석이 실패 할 것으로 예상되는 경우 (예 : 예외적이지 않은 버전) 버전 .
실제로, stof그냥 래퍼로 정의되어 strtof있으므로 예외를 원하지 않으면 해당 예외를 사용하십시오.
그렇다면 특정 기능에 대해 예외를 사용해야하는지 여부를 어떻게 결정해야합니까?
IMHO, 두 가지 경우가 있습니다 :
함수와 같은 "라이브러리"(다른 상황에서 자주 재 사용됨) : 기본적으로 결정할 수 없습니다. 오류를보고하는 버전과 반환 된 오류를 예외로 변환하는 랩퍼 버전을 모두 제공 할 수 있습니다.
"응용 프로그램"기능 (응용 프로그램 코드의 얼룩에 따라 일부는 재사용 될 수 있지만 응용 프로그램 오류 처리 스타일 등에 의해 제한됨) 함수를 호출하는 코드 경로에서 예외없이 유용한 방법으로 예외를 처리하는 경우 예외를 사용하여 오류 를보고하십시오 (아래 참조) . 오류 리턴 스타일에 대해 응용 프로그램 코드를보다 쉽게 읽고 쓸 수있는 경우이를 사용하십시오.
물론 그 사이에 장소가있을 것입니다. 필요한 것을 사용하고 YAGNI를 기억하십시오.
마지막으로 FAQ 문으로 돌아 가야한다고 생각합니다.
함수 사용시 코딩 오류를 나타 내기 위해 throw를 사용하지 마십시오. 프로세스를 디버거로 보내거나 프로세스를 중단하려면 assert 또는 기타 메커니즘을 사용하십시오.
나는 모든 오류이 가입 분명히 뭔가 심각하게 엉망이되어 있는지 또는 호출 코드가 있음을 표시 명확하게 그것이 무엇을하고 있었는지 몰랐다.
그러나 때 이 적절한 따라서 라이브러리 도메인 대 응용 프로그램 도메인 위 참조 종종 높은 응용 프로그램 고유의 것입니다.
이것은 호출 전제 조건 을 확인하는지 여부와 방법에 대한 질문으로 돌아 가지 만 이미 너무 오래 답변하지는 않습니다. :-)