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

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

Я хочу знать, какой метод лучше всего подходит для 1) быстрого кодирования 2) отладки 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);

errno
person Community    schedule 21.11.2008    source источник

Ответы (4)


arrow_upward
8
arrow_downward

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

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

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

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

person Tyler McHenry    schedule 21.11.2008
comment
Errno в стиле C является потокобезопасным; см. stackoverflow.com/questions/449778/ (но я согласен, что он глобальный, поэтому вы никогда не узнаете, кто его сбрасывает). - person user9876; 25.07.2011

arrow_upward
2
arrow_downward

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

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

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

person jdigital    schedule 21.11.2008

arrow_upward
0
arrow_downward

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

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

person Pyrolistical    schedule 21.11.2008

arrow_upward
0
arrow_downward

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

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

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

person Brian C. Lane    schedule 21.11.2008