2014-07-08 1 views
1

해시 테이블 클래스에 여러 가지 예외를 추가하여 발생할 수있는 다양한 문제를 처리했습니다. 그들은 주로 다음과 같이 구성된다 : 무엇을 던지기 위해 통과해야합니까?

std::string msg = std::string("I made doodoo, some value: ") + std::tostring(value); 
throw std::exception(msg.c_str()); 

예외의 일부

정상 작동의 일부, 예를 들어 테이블이 가득라고 한 다음 그것을 잡아 더 큰 하나에 테이블을 다시 작성 것이 있습니다. 나는 이것이 퍼포먼스에 상당한 움푹 들어간 것을 발견했다. 나는 모든 문자열 구성을 의심한다. 동시에, 나는 예외가 의미가 있고, 내가 의미하는 코드 번호가 무엇인지 모르는 누군가에게 의미가 있기를 바란다. 이 문제를 해결하는 좋은 방법은 무엇입니까?

+0

일반적으로 던져 예외는 비쌉니다. 스택을 풀어야합니다. – chris

+2

일반적으로 예외가 throw 될 때까지 오버 헤드가 발생하지 않지만 더 큰 성능 저하가 발생하는 예외가 구현됩니다. 이 경우에는 리팩토링 코드가 프로그램 로직의 일부로 예외를 던지지 않도록 제안합니다. 정말로 예외적 인 경우를 위해 저장하십시오. – UldisK

+1

적어도 사전 정의 된 표준 예외 범주 클래스 (예 : [std :: logic_error'] (http://en.cppreference.com/w/cpp/error/logic_error) 등)에서 자신의 예외 클래스를 만듭니다. Don std :: exception'을 직접 throw하지 않으며 오류와 일치하는 카테고리가없는 한 직접적으로 상속하지 않습니다. –

답변

1

std::exception에서 맞춤 예외 클래스를 생성하는 것이 가장 이상적입니다. 이렇게하면 catch 개의 블록을 만들 때 각 예외에 대해 특정 catch을 가질 수 있습니다. 예 :

class MyException;   // Inherits from std::exception. 
class MyOtherException;  // Inherits from std::exception. 

void foo() 
{ 
    if (bar) 
     throw MyException(); 

    if (baz) 
     throw MyOtherException(); 

    // do stuff. 
} 

int main() 
{ 
    try 
    { 
     foo(); 
    } 
    catch(const MyException &ex) 
    { 
     // Handle MyException. 
    } 
    catch (const MyOtherException &ex) 
    { 
     // Handle MyOtherException. 
    } 
} 

당신이 당신의 예외에 추가 정보를 첨부 할뿐만 아니라, 전술 한 바와 같이 다른 예외 유형을 처리 할 수 ​​있기 때문에 자신의 예외 클래스를 만들기 당신에게 더 많은 유연성을 제공한다.

코드에 대한 주된 문제점은 (최소한 어떻게 설명했는지) 그러나 예외가있는 프로그램 흐름을 제어하는 ​​것처럼 보입니다. 예외는 빠른 구조로 설계되지 않았으므로, 처리되지 않으면 프로그램이 중단되는 예외적 인 경우를 위해 설계되었습니다. if 문 대신 예외를 사용하면 코드가 매우 느리고, 읽기가 어렵고, 이해/유지가 어려워집니다.

예를 들어 해시 테이블에 추가 할 때 테이블의 크기를 조정해야하는 이유가 있다면 크기 조정을 할 때 왜 예외가 발생해야합니까?? 이것은 정확히 std::vector의 작동 방식입니다. vectorvector.capacity() < vector.size() + 1에서 push_back()을 수행하면 벡터는 내부적으로 버퍼를 다시 할당하여 새 항목을 추가 할 수 있습니다. 예외가 발생할 수있는 유일한 시간은 메모리가 부족한 경우입니다. 발신자가이 사실을 알지 못하면 단지 vector.push_back(...)을 호출합니다.

+0

내 테이블은 작은 오버 플로우로 선형으로 제한됩니다 (이 테스트에서이 버전은 최고의 성능을 제공했습니다). 일반적으로 ~ 70-80 % 정도의 값이 가득 찼지 만 시도하지 않고 정확히 알 수는 없습니다. 데이터가 물리적으로 메모리 맵핑 된 파일에 있기 때문에 크기를 조정하는 것은 굉장한 시련입니다. 따라서 주 테이블 클래스를 일정한 크기로 만들고 파괴적인/래퍼 클래스로 다시 작성하여 훨씬 더 깨끗하게 만듭니다. 지금은 일반 작업의 모든 예외를 반환 값을 부 풀리도록 변경했습니다. 그런 식으로 계속 유지할 것입니다. –

관련 문제