Почему выбрасывается исключение, считающееся плохим дизайном?

Question

У меня есть код для сортировки вектора объектов. Если какой-либо из объектов недействителен, я хочу немедленно прекратить сортировку и сообщить об ошибке. В ошибке я хочу включить описание недопустимого объекта (независимо от того, какой из них существует).

Это мой код (не полный, но я надеюсь, что вы можете следовать за мной):

int sortProc(const Bulk & b1, const Bulk & b2) { 
    if (!b1.isValid()) throw b1; 
    if (!b2.isValid()) throw b2; 
    return b1.compareTo(b2); 
} 

vector<Bulk> * items = getItems(); 
try { 
    sort(items->begin(), items->end(), sortProc); 
} catch (const Bulk & item) { 
    cout << "Cannot sort item: " << item.description(); 
} 

Теперь я немного неуверенный моего кода, потому что я слышал, что все исключения должны наследоваться класс исключения, и считается ошибочной практикой бросать объекты, которые не являются исключениями, но я действительно не понимаю, почему. Мой код выше работает, что-то не так с ним? Это серьезный вопрос, поэтому, если вы увидите какие-то проблемы, я был бы рад узнать. Я не ищу моральных проблем.

Answer 1

Я не ищу моральных проблем.

Вы не можете задавать вопрос стиля, а затем запрещать все ответы на основе «моральных проблем», если вы планируете выяснить это.

Некоторые люди считают, что бросание только объектов типов, полученных std::exception, обеспечивает согласованность интерфейса, поскольку вы можете вызывать .what() на всех из них и объединить их на верхнем уровне вашей программы. Вы также можете гарантировать, что другие единиц перевода — те, кто никогда не слышал о вашем классе Bulk — смогут получить исключение, если они хотят (если только как std::exception).

• Является ли ваша программа неправильно? №

• Работает ли это? Да, конечно.

Но иногда просто «работа» не считается достаточным, и нам нравится быть немного более аккуратным о вещах.

Это действительно так ...

Answer 2

Это не про мораль. Речь идет не о функциональности. Дело не в правильности. Речь идет о логике вашего кода.

Помните, что код отражает то, как вы думаете. Ясный мыслящий разработчик никогда не бросит «исключение», которое действительно не является причиной исключения, которая просто путает логику.

Joker_vD также прав относительно производительности кода, но я не думаю, что вы еще там.

Answer 3

Я вижу (может быть, серьезную) проблему с массовым переносом данных ввода и отказа. Наличие производной формы BulkException std :: exception - это очиститель!

Несмотря на то, что состояние, указывающее на сбой, является прекрасным, я думаю, что использование класса для переноса отказа не является хорошим.

Ошибка BulkException может собрать дополнительную информацию (например, трассировку стека), которая бесполезна для нормальной работы.

Answer 4

Вот код очень похож на ваш, за исключением того, что не имеет контроля потока с произвольным доступом:

std::unordered_set<std::string> errors; 
auto sortProc = [&errors](const Bulk & b1, const Bulk & b2)->int { 
    if (!b1.isValid()) errors.insert(b1.description()); 
    if (!b2.isValid()) errors.insert(b2.description()); 
    if (!b1.isValid()||!b2.isValid()) 
    return b1.isValid()<b2.isValid(); 
    return b1.compareTo(b2); 
} 

vector<Bulk> * items = getItems(); 
sort(items->begin(), items->end(), sortProc); 
if (!errors.empty()) { 
    std::cout << "Unsortable items found while sorting:\n"; 
    for (auto const& e : errors) { 
    std::cout << e << "\n"; 
    } 
} 

Я предпочитаю избежать случайного контроля потока доступа, кроме исключительных обстоятельств. Функция sort может продолжать игнорировать отказ элемента в isValid, поэтому он должен по умолчанию вместо того, чтобы управлять потоком управления на основе исключаемого интерфейса.

Хотя заманчиво использовать исключения как способ возврата «второго возвращаемого значения», результат заключается в том, что интерфейс вашего кода становится скрытым и сочетается с деталями реализации как вашего кода, так и кода, который использует ваш код ,

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

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

Answer 5

Почему выбрасывается исключение, если не считать плохой дизайн?

Потому что редко системы существуют в вакууме.

Исключения служат основной целью: создать пакет информации об ошибке или каком-либо другом «исключительном» условии и распространить эту информацию через границы без учета местонахождения этих границ.

Рассмотрим последнюю часть тщательно:

без учета местности этих границ.

Вы можете думать о исключительного состояния как тот, который должны быть участием в некотором роде. Если есть кусок кода, который может справиться с этим, тогда этому коду должна быть предоставлена ​​такая возможность. Если не существует кода, который может его обслуживать, программа должна умереть.

В этом контексте пакет информации, описывающий исключительное условие, должен свободно протекать через любую часть программы - даже те, которые вы лично не пишете, или даже подумали, что когда-нибудь будет написан ваш проект простой проблеск в вашем глазу. Для того, чтобы это работало, все исключения должны быть написаны с использованием знакомого протокола. То есть отдаленные обработчики исключений должны иметь возможность понять, по крайней мере, основную информацию, содержащуюся в пакете. Все должны говорить на одном языке.

Как это обычно делается в C++, путем получения всех объектов исключения из std::exception. Таким образом, обработчик в обширной части кода - возможно, даже код, о котором вы даже не мечтали написать, - может, по крайней мере, сообщить об исключительном случае, прежде чем программа встретится с кончиной. Возможно, он сможет справиться с ситуацией и позволить программе жить, но это часто невозможно.

Answer 6

Хороший дизайн о качестве.Правильно ли ваш код? Минимизирует ли он зависимости от внешних объектов? можно ли его повторно использовать? Это понятно? Устраняет ли это избыточность? Вы можете проверить его? Могут ли другие люди прочитать это и узнать, что он делает? Этот последний вопрос действительно тяжелый, потому что вы не другие люди - вы - автор.