бросить, вернуть или ошибиться?

Question

я создаю систему. Что я хочу знать, если сообщение не поддерживается, что он должен делать? я должен бросить, говоря неподдерживаемый MSG? я должен вернуть 0 или -1? или я должен установить errno (base-> gr; errno_). Некоторые сообщения мне было бы все равно, если произошла ошибка (например, setBorderColour). Другие я бы (addText или, возможно, сохранить, если я создаю команду сохранения).

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

Система работает примерно так, но не совсем так. Это стиль C, а в mycode есть несколько встроенных функций, которые переносят settext (const char * text) {в msg (this, esettext, text)

Base base2, base;
base = get_root();
base2 = msg(base, create, BASE_TYPE);
msg(base2, setText, "my text");
const char *p = (const char *)msg(base2, getText);

Answer 1

Обычно, если это C ++, предпочитайте исключения, если производительность не критична или если вы не работаете в среде (например, во встроенной платформе), которая не поддерживает исключения. Исключения - безусловно лучший выбор для отладки, потому что они очень заметны, когда они происходят, и игнорируются. Далее, исключения являются самодокументируемыми. У них есть собственное имя типа и, как правило, отдельное сообщение, объясняющее ошибку. Коды возврата и, следовательно, требуют отдельных определений кода и какого-то внеполосного способа сообщения о том, что коды значат в любом данном контексте (например, справочные страницы, комментарии).

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

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

Правка . Я только что понял, что вы имели в виду переменную-член errno, а не errno в стиле C. Это лучше в том смысле, что он не глобален, но вам все еще нужны дополнительные конструкции, чтобы сделать его поточно-ориентированным (если ваше приложение многопоточное), и он сохраняет все проблемы кода возврата.

Answer 2

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

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

Тем не менее, есть некоторые проблемы с дизайном, связанные с обработкой исключений, и если вы ошибетесь, вам будет хуже. Короче говоря, если вы пишете код, который не знаете, как обрабатывать исключение, вы должны позволить ему распространяться. Слишком много кодеров перехватывают ошибки только для того, чтобы преобразовать исключение, а затем снова его выбросить, в результате чего получается код исключения спагетти, который иногда теряет информацию о первоначальной причине проблемы. Это предполагает, что у вас есть обработчики исключений на верхнем уровне (точки входа).

Answer 3

Лично, когда дело доходит до вывода графики, я чувствую, что тихий сбой - это нормально. Это просто делает вашу фотографию неправильной.

Графические ошибки очень легко обнаружить в любом случае.

Answer 4

Лично я бы добавил errno к вашей структуре Base, если это чистый 'C'. Если это C ++, я бы выбросил исключение.

Это зависит от того, насколько «фатальными» являются эти ошибки. Пользователь действительно должен видеть ошибку, или это для назидания других разработчиков?

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