| Меню сайта |
|
 |
| Категории раздела |
|
|
| Поиск |
|
|
|
Стоит ли проверять код ошибки
Стоит ли проверять код ошибки и в каких случаях это требуется.
В каких случаях запрашивается код ошибки:
1. Для определения, стоит ли выполнять последующие операции или направить по другой ветви операций.
2. Сообщить пользователю, что его пожелания не выполнены.
3. Передать внешней программе
Ответы:
Код ошибки
Код ошибки позволяет определить, что функция выполнена и её результат можно принимать как достоверные данные. Часто возвращаемое значение функции может являтся сигналом о недостоверности данных, например при возвращении чисел от 0 и более сигналом ошибки может быть "-1", так как это число не входит в диапазон валидных чисел. Если возвращаемые данные охватывают весь диапазон чисел, то возвращаемые данные не могут являтся сигналом ошибки, в этом случае используется макрос @error. При завершении функции, созданной пользователем, макросу @error принудительно присваевается 0, даже если внутренние нативные функции возвращали ошибку и @error не был равен 0. Изменить @error для пользовательской функции можно только принудительно используя функцию SetError. В данном случае с помощью макроса @error программист сам назначает код ошибки на основе ошибок возвращаемых нативными функциями. Во всех случаях, если @error не равен 0, значит произошла ошибка. Это правило не следует нарушать для пользовательских функций, так как макрос @error не содержит иных данных кроме кода ошибки.
1. Для определения, стоит ли выполнять последующие операции или направить по другой ветви операций.
Проверка ошибки не обязательна
Случай когда ошибку проверять не обязательно. Для примера возьмём комбинацию функций FileOpen, FileWrite, FileClose. Теоретически после FileOpen требуется проверить код ошибки, чтобы позволить сделать запись FileWrite и закрыть дескриптор файла FileClose. А практически FileOpen при ошибке возвращает -1, гепотетически для FileWrite и FileClose это значение не является валидным и функции сработают в холостую. То есть операции FileWrite, FileClose проверят входное значение и выполнят Return. Это пример того, как функции внутренним движком проверяют ошибку и иногда можно игнорировать проверку ошибки FileOpen и возможно других функций. Пользователю также не обязательно сообщать, что не удалось создать конфигурационный файл сохраняющий текущие настройки, ведь вероятнее всего он об этом знает, если запуск произошёл с CD-диска и данные не являются сохраняемыми данными пользователя. Напротив, лишние предупреждения делают утомительной работу с программой.
Проверка ошибки обязательна
Например после события выполняется ресурсоёмкая по нагрузке на процессор функция или длительная по времени или нарушающая логику программы.
а) Проверка как единственный критерий ошибки
Например по условию должен создаться массив, но ввиду отсутствия данных этого не произошло. По умолчанию пустой массив создать нельзя (на версиях до 3.3.8.1) и соответственно нельзя возвратить пустой массив, а обработка массива с одним элементом неправильна, так как этот случай считается валидным. Единственный выход в такой ситуации либо возвращать код ошибки, либо задать формат массива, в котором первый элемент содержит число полученных элементов массива. В некоторых функциях (StringRegExp) не удаётся получить такой массив и приходится использовать возврат кода ошибки. Дело в том что обработка цикла от $i=1 до 0 ($array[0]=0) не выполняется, поэтому код ошибки можно не проверять, а для массива без счётчика в $array[0] нужно проверить ошибку перед тем как запускать цикл от $i=0 до UBound($array)-1 так как UBound($array)-1 равен 0, то цикл выполнит один шаг, а это не правильно по логике программы.
б) Выполняется ресурсоёмкая или длительная функция
Здесь важно расставить приоритеты выполнения операций. Например если для выполнения какой либо операции требуется сбор данных от 3-х источников, то первым лучше выполнить запрос данных с менее ресурсоёмкими затратами, возможно этот критерий включит запрет на дальнейший сбор информации. И если возвращается @error указывающий ошибку, то предотвратит холостой ход работы программы.
с) Нарушается логика программы
Случай когда дальнейшее выполнение кода может спровоцировать непредсказуемые последствия. Например когда данные не соответствуют формату или необходимой размерности и программа может выдать неправильную информацию или завершиться крахом. С одной стороны не делать излишние проверки после каждой функции, с другой стороны не допускать случая когда ошибочные данные могут быть приняты как валидные при передаче следующему блоку операторов.
2. Сообщить пользователю, что его пожелания не выполнены.
Здесь ответ однозначно "Да". Если информация важна или что операция успешно завершена, это говорит пользователю что его требования выполнены или не выполнены с указанием причин невыполнения.
3. Передать внешней программе
Здесь ответ однозначно "Да". Также как и внутренние функции определяют дальнейшее развитие событий, то тем более целые программы.
ПС:
Ресурсоёмкость проверки кода ошибки настолько мала по сравнению с любой выполняемой функцией, что лучше вызвать проверку лишние 10 раз, чем заложить скрытую ошибку в программу. Это всего лишь проверка целого числа int, что число не равно 0. Макрос @error это всего лишь зарезервированная ячейка памяти, в которой храниться число определяющее успешность выполнения последней функции (если для данной функции установка значения @error документируется). |
| Категория: Примеры скриптов | Добавил: AZJIO (23.12.2013)
|
| Просмотров: 1614
| Рейтинг: 0.0/0 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ] |
|
| Вход |
|
|
| Статистика |
Онлайн всего: 1 Гостей: 1 Пользователей: 0 |
|
| ЮMoney |
Мой кошелёк
ЮMoney: 4100117604217624
|
|
|
