1
사전 및 사후 조건이있는 메소드가 있다고 가정합니다. 완료되지 않은 각 사전 조건에 대해 예외 클래스를 만드는 것이 좋습니까? 예 : pre1을 수행하지 않으면 notPre1Exception 인스턴스가 발생합니다.전제 조건 및 예외 사항
A
답변
3
예 아니요.
예 - 사전 조건 위반은 확실히 예외를 throw하는 적절한시기입니다. 보다 구체적인 예외를 던지면 해당 예외를보다 쉽게 잡을 수 있습니다.
아니요 - 프로그램/api의 모든 전제 조건에 대해 새로운 예외 클래스를 선언하는 것은 과도한 것처럼 보입니다. 결국 수백 또는 수천 가지 예외가 발생할 수 있습니다. 이것은 정신적으로나 컴퓨터 적으로 낭비되는 것 같습니다.
전제 조건 위반에 대해 예외를 throw하는 것이 좋습니다. 그러나 각 전제 조건에 대해 새로운 예외를 정의 할 것을 권장하지는 않습니다. 대신 특정 전제 조건 위반이 아닌 유형의 사전 조건 위반을 다루는 광범위한 예외 클래스를 만드는 것이 좋습니다. (나는 또한 잘 맞는 곳에 기존 예외를 사용하는 것이 좋습니다.)
1
사전 조건을 충족시키지 못하는 경우에만 희귀 한 이 발생하고 예외가 발생합니다.
1
나에게 예외를 유용하게 사용하는 것처럼 들립니다. 그것은 하나의 '전제 조건 실패'예외를 가질 수도 있지만 예외 조건에 실패한 것을 예외 메시지에 넣을 수는 있지만 일반적인 '전제 조건 실패'보다 더 세분화 된 로깅 및 디버깅을 확실히 허용합니다.
9
왜 PreconditionFailedException (문자열 전제 조건)을 정의 하시겠습니까? 실패한 각각의 전제 조건에 대해 다른 예외 유형을 던지는 것은 잔인합니다.
1
나는 당신이 그들을 사용하고 취급하는 한 당신의 모든 예외에 대해 다른 예외를 만드는 것이 좋다라고 생각한다.
오류/예외 처리가 잘되면 나중 단계에서 소프트웨어를 디버그하는 것이 더 쉽다는 것을 발견했습니다.
예 : 잘못된 입력을 모두 처리하는 일반적인 경우에는 오류가있는 경우 메서드에 전달 된 모든 것을 확인해야합니다. 나쁜 조건의 모든 유형의 excpetion가있는 경우에 당신은 exaclty를 볼 것이다 곳에.
1
나에게도 보이지만, 이런 전제 조건을 계속 수행하려면 클래스 메소드마다 N 개의 예외 클래스가 필요합니다. '비 기능적'수업이 폭발적으로 증가한 것처럼 보입니다.
저는 '핵심'기능이 전제 조건 위반을 처리하지 않는 코드를 항상 좋아했습니다 (큰 도움이되었습니다!). 이 코드는 이 예외를 던지거나 그렇지 않으면 만족하지 않음을 알리는 'precondition-checker'에 래핑 될 수 있습니다.
1
클래스를 만들지 말아야하는지 (그리고 예외는 클래스인지) 결정하는 매우 일반적인 방법으로,이 클래스를 다른 모든 클래스와 고유하게 만드는 코드가 있는지 예외).
그렇지 않으면 예외로 문자열을 설정하고 하루로 지정합니다. 예외에서 코드를 실행하는 경우 (아마도 exception.resolve() 또는 다른 것을 호출하여 여러 상황을 처리 할 수있는 일반적인 복구 메커니즘)이 유용 할 수 있습니다.
예외가 항상이 규칙을 따르는 것은 아니지만, 언어에서 제공하는 예외가 비즈니스 로직을 가질 수 없기 때문에 다소 차이가 있다고 생각합니다 (왜냐하면 비즈니스 라이브러리를 모르기 때문에 항상 OO 규칙에 대한 예외로 가득 찬 경향이있다.)
2
실패한 전제 조건은 AssertException 또는 유사한 것을 던져야한다. 메소드를 호출하기 전에 반드시 전제 조건을 설정해야합니다. 호출자가이 검사를 수행하지 않으면 프로그램의 버그이거나 메소드 (API)의 잘못된 사용입니다.
0
Java RuntimeException의 하위 클래스 인 확인되지 않은 예외로 만들면 괜찮다고 말할 수 있습니다. 그러나 Java에서는 어설 션을 사용하는 것이 좋습니다.
1
저는 벤이 여기에 있다고 생각합니다. 다른 예외를 던질 때 그 점을 잡으려하지 않으면 어떻게됩니까? 정말로 다른 것을 던지기를 원한다면 적어도 공통적 인 "PreconditionFailedException"기본 클래스를 가지게 될 것입니다. 그리고 그것들을 그룹화 할 수 있도록 일종의 영안에 정리하려고합니다. Personlly, 나는 다른 것들을 가지지 않을 것이고, 당신이 각각의 실패의 세부 사항을 던지는 공통의 예외를 가지고 있습니다.
0
이렇게하면 다른 모든 사용자 지정 예외에서 모두 상속되는지 확인하십시오.
1
아니요, 계약별로 설계 원칙에 위배되므로 각 전제 조건에 대해 특정 예외를 만들지 않아야합니다.
사전 조건을 구현할 때의 결론은 설명서의 일부 여야하며 호출자가 모든 전제 조건이 유효한지 확인하는 데 필요한 메소드를 제공해야한다는 것입니다. (즉, 메소드 실행이 객체의 상태에 의존하는 경우 상태를 확인하는 메소드가 호출자에게 제공되어야합니다).
따라서 호출자는 메소드를 호출하기 전에 모든 전제 조건이 충족되는지 확인할 수 있어야합니다.
위반 된 각 조건에 대해 특정 예외를 구현하면 호출자가 메서드 호출과 함께 try/catch 패턴을 사용하도록 유도 할 수 있지만 설계 상 계약의 철학과 모순되는 것은 무엇입니까?
또한 일반적인 전제 조건 예외 유형은 어떤 조건이 실패했는지 쉽게 설정할 수있는 매개 변수 (예 : 문자열 또는 열거 형)를 사용할 수 있습니다. –