Стоит ли всегда писать код для других случаев, которые «никогда не произойдут»? - PullRequest
Новая
       30

Стоит ли всегда писать код для других случаев, которые «никогда не произойдут»?

19 голосов
/ 19 марта 2010

Возьми какой-нибудь код вроде 

if (person.IsMale()) {
    doGuyStuff();
} else {
    doGirlStuff();
}

Должно ли это быть написано, чтобы явно проверить, если person.isFemale(), а затем добавить новый else, который вызывает исключение? Возможно, вы проверяете значения в перечислении или что-то в этом роде. Вы думаете, что никто не будет добавлять новые элементы в перечисление, но кто знает? «Никогда не бывает» звучит как знаменитые последние слова.

Ответы [ 14 ]

0 голосов
/ 20 марта 2010

Поскольку ответов так много, я просто покажу вам, как это переусердствовать: (в C ++) 

if(!DoOperation())
{
    // Allocate for a message
    char * pMsg = new char[256];
    // Make sure the memory was allocated
    if(!pMsg)
    {
        cout << PREDEFINED_OUT_OF_MEMORY_MESSAGE << endl;
        exit(0);
    }

    if(!strcpy(pMsg,"Operation failed!"))
    {
        cout << PREDEFINED_STRCPY_FAILED_MESSAGE << endl;
        exit(0);
    }

    // Now let the user know there was an error
    ErrorDetailStructure * pError = new ErrorDetailStructure();
    if(!pError)
    {
        cout << PREDEFINED_OUT_OF_MEMORY_MESSAGE << endl;
        exit(0);
    }

    // Copy the message to the error structure
    if(!strcpy(pError->pMessage,pMsg))
    {
        cout << PREDEFINED_STRCPY_FAILED_MESSAGE << endl;
        exit(0);
    }

    // Alert the user - yes, ErrorDetailsStructure
    // overloads operator<<
    cout << pError;

    delete pError;  // the destructor frees pMessage member

    // Now we need to log this error
    some_file_pointer * pFile = OpenAFilePointer("/root/logfile");

    if(!some_file_pointer)
    {
        cout << PREDEFINED_OPEN_FILE_ERROR_MESSAGE << endl;
        exit(0);
    }

    some_file_pointer->WriteError("Something went wrong. Guess what it was.");

    // Don't forget to free some_file_pointer
    delete some_file_pointer;

    exit(0);  // Just quit. Give up.
}

Мне это очень понравилось. С этим так много проблем (и дизайн такой плохой), что я даже посмеялся над этим.

0 голосов
/ 19 марта 2010

Вопрос зависит от вашего контекста - сможет ли кто-нибудь еще когда-либо расширить ваш объект Person? Когда андроиды становятся законными людьми, вы можете обнаружить, что isMale () и isFemale () могут быть ложными.

Это особенно актуально, если код, который вы пишете, является модулем, который будет использоваться людьми вне вашей группы. Конечно, в этом случае вы можете пойти дальше, пропустить жестко запрограммированные тесты if и вызвать doGenderStuff () для объекта, созданного соответствующей фабрикой ...

0 голосов
/ 19 марта 2010

Лично я бы написал строку else как: 

} else /*if (person.IsFemale())*/ {

Это обходит необходимость запуска функции (я бы не хотел тратить время на ее запуск, если ее результаты не нужны), но оставляет важную документацию для будущих разработчиков. Теперь ясно, что эта ветвь условия охватывает случай IsFemale (в частности), а не случай !IsMale (в целом). По сути, вы делаете свои предположения «вслух», что снижает вероятность того, что будущие изменения неправильно поймут, что вы делаете, и нарушат ваш код.

В наших встроенных системах может быть сложно анализировать и отлаживать сбои, поэтому мы часто включаем «невозможные» операторы else и заставляем их выплевывать сообщения об ошибках и генерировать исключения. Обычно это ограничивается разработкой, и когда код становится стабильным, он удаляется.

0 голосов
/ 19 марта 2010

Если этого не произойдет, вам не нужно писать код для него.

Страница:
...