Ошибка проверки излишним?
Какую проверку ошибок вы делаете? Какая проверка ошибок действительно необходима? Нужно ли проверять, успешно ли сохранен файл? Разве это не должно работать всегда, если оно проверено и работает нормально с первого дня?
Я обнаруживаю, что проверяю ошибки для каждой мелочи, и большую часть времени чувствую себя излишним. Такие вещи, как проверка, чтобы убедиться, что файл был успешно записан в файловую систему, проверка, чтобы проверить, не завершился ли оператор базы данных....... не должно ли это быть тем, что работает или не работает?
Сколько ошибок вы делаете? Существуют ли элементы проверки ошибок, которые вы пропускаете, потому что вы уверены, что это просто сработает?
Я уверен, что помню, что где-то читал что-то вроде "не проверяйте вещи, которые никогда не произойдут на самом деле"… хотя не могу вспомнить источник.
Так должно ли быть проверено все, что может потерпеть неудачу? Или мы должны просто доверять этим более простым операциям? Например, если мы можем открыть файл, должны ли мы проверить, не было ли чтение каждой строки неудачным или нет? Возможно, это зависит от контекста в приложении или самого приложения.
Было бы интересно услышать, что делают другие.
ОБНОВЛЕНИЕ: В качестве быстрого примера. Я сохраняю объект, который представляет изображение в галерее. Затем я сохраняю изображение на диск. Если сохранение файла не удастся, мне нужно будет отобразить изображение, даже если объект думает, что изображение есть. Я мог бы проверить, не удалось ли сохранить изображение на диск, а затем удалить объект, или, в качестве альтернативы, обернуть изображение в транзакцию (единицу работы), но это может обойтись дорого, если использовать механизм обработки БД, использующий блокировку таблицы.
Спасибо,
Джеймс.
5 ответов
Если у вас заканчивается свободное место и вы пытаетесь записать файл и не проверяете ошибки, ваше приложение будет зависать тихо или с глупыми сообщениями. Я ненавижу, когда вижу это в других приложениях.
Я не рассматриваю весь вопрос, только эту часть:
Так должно ли быть проверено все, что может потерпеть неудачу? Или мы должны просто доверять этим более простым операциям?
Мне кажется, что проверка ошибок наиболее важна, когда важен следующий шаг. Если неудача при открытии файла приведет к потере сообщений об ошибках, то это проблема. Если приложение просто умрет и выдаст пользователю ошибку, то я бы посчитал это проблемой другого рода. Но молчаливая смерть или молчаливое зависание - это проблема, против которой вам следует приложить все усилия, чтобы кодировать. Поэтому неважно, является ли что-то "простой операцией" или нет; это зависит от того, что будет дальше, или каков будет результат в случае неудачи.
Я обычно следую этим правилам.
- Чрезмерно проверяйте пользовательский ввод.
- Проверьте общедоступные API.
- Используйте утверждения, которые скомпилированы из производственного кода для всего остального.
Возможно, это не тот ответ, который вы ищете, но всегда есть "правильный" ответ, если рассматривать его в полном контексте того, что вы пытаетесь сделать.
Если вы пишете прототип для внутреннего использования, и если вы получаете странную ошибку, это не имеет значения, то вы тратите время и деньги компании, добавляя дополнительную проверку.
С другой стороны, если вы пишете производственное программное обеспечение для управления воздушным движением, то дополнительное время для обработки каждой мыслимой ошибки может быть потрачено не зря.
Я рассматриваю это как компромисс - дополнительное время, затрачиваемое на написание кода ошибки, по сравнению с преимуществами обработки этой ошибки, если и когда она возникает. Религиозно обрабатывать каждую ошибку не обязательно оптимально ИМО.
Что касается вашего примера...
Я сохраняю объект, который представляет изображение в галерее. Затем я сохраняю изображение на диск. Если сохранение файла не удастся, у меня будет [no] изображение для отображения, даже если объект думает, что изображение есть. Я мог бы проверить, не удалось ли сохранить изображение на диск, а затем удалить объект, или, в качестве альтернативы, обернуть изображение в транзакцию (единицу работы), но это может обойтись дорого, если использовать механизм обработки БД, использующий блокировку таблицы.
В этом случае я бы рекомендовал сначала сохранить изображение на диск перед сохранением объекта. Таким образом, если изображение не может быть сохранено, вам не нужно пытаться откатить галерею. Как правило, зависимости должны записываться на диск (или помещаться в базу данных) в первую очередь.
Что касается проверки ошибок... проверьте наличие ошибок, которые имеют смысл. Если fopen() дает вам идентификатор файла, и вы не получаете сообщение об ошибке, тогда вам обычно не нужно проверять fclose() для этого идентификатора файла возвращается "неверный идентификатор файла". Если, однако, открытие и закрытие файла являются непересекающимися задачами, было бы неплохо проверить эту ошибку.