Техника обработки ошибок для процедурного аппаратного программирования
Я пишу код на C ++, который управляет специальным устройством, объединяющим несколько SDK. Мой код выглядит
#define sdk1SafeCall(err) __sdk1SafeCall(err,__FILE__,__LINE__)
int errorcode = 0;
sdk1SafeCall(sdk1_InitializeDevice());
errorcode=sdk2_InitializeDevice();
errorcode=sdk3_InitializeDevice();
if (some_parameter)
{
errorcode=sdk2_readDevice(true);
}
else
{
errorcode=sdk3_writeDevice();
}
label again: errorcode=sdk1_readDevice();
if (error) goto again;
errorcode=close_everything();
Использование параметров переставит поток управления. Мой текущий метод использует что-то вроде cudaSafeCall для переноса кодов ошибок и выхода. Чего я не знаю, как это сделать, так это где хранить подробные объяснения этих ошибок или как их устранить (например, пример goto). В конце дня код выглядит действительно грязным.
редактировать
Я иногда обрабатываю ошибки с помощью обертки.
Решение
Писать код, безопасный для ошибок, сложно. В вашем псевдокоде вы вообще не имеете дело с ошибками. errorcode будет просто иметь результат «close_everything ()», что может быть успешным, даже если все остальное пошло не так.
Типичный способ решения такого рода вещей в C ++ состоит в том, чтобы иметь объект для каждого «ресурса» (например, «устройства»), и throw exception если что-то пойдет не так, от чего вы не ожидаете восстановления. Оберните всю функцию [или внешний набор функций] в try/catch блок.
Конечно, если «сбой — это нормально» (например, вы пытаетесь прочитать данные с сетевого порта и получаете тайм-аут из-за отсутствия доступных данных, это не то, для чего вы должны генерировать исключение). Это должно использовать возвращаемое значение.
Обратите внимание, что использование объектов для обработки ресурсов требует тщательного проектирования кода и особенно того, что ваш деструктор хорошо справляется с очисткой — он запускается после исключения. Убедитесь, что вы не оставляете вещи позади, если вы бросаете исключение в конструктор — так вы получаете утечки.
Естественно, существует целый ряд других решений — в конце концов, мы говорим о программировании, поэтому всегда есть как минимум 11 различных способов что-то решить.
Другие решения
Других решений пока нет …