Сохраненные процедуры могут возвращать целое число, которое называется кодом возврата (return status). Это число показывает, была ли процедура выполнена полностью или указывает на причины неудачного выполнения. SQL Сервер имеет набор заранее определенных кодов возврата. Пользователю может определить свои собственные коды возврата. Ниже приведен пример пакета, в котором оператор execute возвращает код состояния:
Зарезервированные значения кодов возврата
SQL Сервер резервирует код 0 для указания успешного выполнения процедуры и значения в диапазоне от -1 до -99 для указания различных причин неудачи. В следующей таблице показаны коды возврата от 0 до -14 и даны их описания:
Таблица 14-1: Зарезервированные значения обратного статуса
| Код | Значение |
| Процедура выполнена без ошибок | |
| -1 | Отсутствует объект |
| -2 | Ошибка в типе данных |
| -3 | Прекращение выполнения процедуры для выхода из тупика |
| -4 | Нарушение прав доступа |
| -5 | Синтаксическая ошибка |
| -6 | Ошибка пользователя |
| -7 | Недостаток ресурсов, например, памяти |
| -8 | Не фатальная внутренняя проблема |
| -9 | Достижение системного предела |
| -10 | Фатальная внутренняя проблема |
| -11 | Фатальная внутренняя проблема |
| -12 | Испорчена таблица или индекс |
| -13 | Испорчена база данных |
| -14 | Аппаратная ошибка |
Как забрать деньги у брокера-мошенника? Схемы, которые могут помочь
Кода от -15 до -99 зарезервированы для дальнейшего использования SQL Сервером.
Если во время выполнения процедуры возникает несколько ошибок, то возвращается наибольший по абсолютной величине код.
Коды возврата пользователя
Пользователь может определить свои собственные коды возврата из сохраненных процедур, добавляя параметр в операторе return (возврат). Коды от 0 до -99 зарезервированы SQL Сервером; остальные значения можно использовать для определения своих кодов. В следующем примере возвращается 1, если книга имеет правильный код контракта, и 2 во всех остальных случаях:
Источник: studopedia.org
Коды возврата vs исключения — битва за контроль ошибок
Судя по всему, неделя исключений на хабре успешно наступила :). Накопив достаточную «подушку» кармы чтобы не бояться уйти в минус, я, пожалуй, тоже выскажу свое мнение по данному вопросу. Сразу оговорюсь, что мнение сугубо личное, основанное на небольшом практическом опыте коммерческой разработки: C++, Objective-C, C#, Java, Python, Ruby.
Что такое ошибка?
- Самое простое что в программе может случиться — это сбой операционной системы или железа. Не сработавший системный вызов CreateEvent() или pthread_mutex_lock(), деление на ноль, мусор в результатах системного вызова — все это может случиться по разным причинам, начиная от вышедшего из строя железа и заканчивая вирусами в системе, но как правило от нас и нашей программы это не очень зависит.
- Чуть более сложная ситуация — это отсутствие нужных нам ресурсов. Неожиданно может закончиться память, хэндлы, файловые дескрипторы. Может не быть прав на запись или чтение нужных файлов. Пайп может не открыться. Или наоборот — не закрыться. Доступ к базе данных может быть — а может и не быть. Такая ситуация уже может быть вызвана как нашей программой (слишком много памяти восхотелось) так и нестабильностью системы (вирусу слишком много памяти восхотелось).
- А самая распространенная ситуация — это ошибка в логике программы или взаимодействия ее частей. Мы пытаемся удалить несуществующий элемент списка, вызывать метод с неверными аргументами, многопоточно выполнить неатомарную операцию. Как правило это приводит или к некорректному поведению программы («тулбар исчез») или к ее краху с access violation / unhandled exception.
Как видите, много всего разного и нехорошего может произойти — а ведь это далеко не полный список :). А что делать программисту? Тут, на мой взгляд, перед нами встает очень интересный и важный вопрос — как именно нашей программе реагировать на ту или иную ошибку? Пожалуй сейчас я еще раз напомню, что излагаю свое сугубо личное мнение.
КАК ЗАРАБОТАТЬ НА ЧЕКАХ?! СКАНИРУЙ ЧЕКИ ИЗ МАГАЗИНА И ЗАРАБАТЫВАЙ! ПРИЛОЖЕНИЕ QROOTO
И скажу следующее — как именно реагировать на ошибку целиком зависит от конкретной программы. Если у нас закончилась память в драйвере — мы должны любой ценой выжить, чтобы пользователь не получил синего экрана смерти. Если же у нас закончилась память в игрушке типа веселая ферма — то имеет смысл упасть, извиниться и попросить отправить багрепорт разработчику.
Системный сервис, призванный крутиться многие месяцы без перезагрузки, должен с пониманием отнестись к ошибке CreateEvent(). Та жа ошибка в прикладной программе типа Photoshop означает что скорее всего система через секунду умрет, и лучше честно упасть, нежели попытаться проглотить ошибку, дать пользователю сохранить файл и благополучно его испортить из-за последующего сбоя во время записи.
Следовательно ошибки мы можем делить на ожидаемые и неожиданные. Для разных программ и разных требований одни и те же ошибки могут считаться как ожидаемыми, так и неожиданными. С ожидаемыми ошибками мы как-то работаем. Не получилось открыть файл — говорим об этом пользователю и продолжаем работу.
Не удалось выделить память для загрузки туда гигабайтного файла — говорим об этом пользователю и продолжаем работу. С неожиданными ошибками мы в большинстве случаев не работаем. Закончилась память при попытке выделить двадцать байт для создания объекта — падаем. Не создался системный объект которых на всю программу три штуки — падаем.
Не читается системный пайп который по спецификации должен читаться? Лучше упасть, чем оставить программу в нестабильном состоянии и потом испортить пользователю данные. Программу он если что перезапустит, а вот за испорченный файл возненавидит до конца дней своих. А для серьезных случаев есть автосейв и перезапускающий нас ежели чего watchdog.
Что было до исключений?
-
Подход два в одном — функция возвращает FALSE или нулевой указатель как для ожидаемой, так и для неожиданной ошибки. Такой подход как правило применялся в API общего назначения и коде пользовательских программ, когда большую часть ошибок можно было смело считать фатальными и падать. Для тех редких случаев когда делить было все же нужно использовалась некая дополнительная машинерия вида GetLastError(). Фрагмент кода того времени, копирующего данные из одного файла в другой и возвращающего ошибку в случае возникновения любых проблем:
BOOL Copy( CHAR* sname, CHAR* dname ) < FILE *sfile = 0, *dfile = 0; void* mem = 0; UINT32 size = 0, written = 0; BOOL ret = FALSE; sfile = fopen( sname, «rb» ); if( ! sfile ) goto cleanup; dfile = fopen( dname, «wb» ); if( ! dfile ) goto cleanup; mem = malloc( F_CHUNK_SIZE ); if( ! mem ) goto cleanup; do < size = fread( sfile, mem, F_CHUNK_SIZE ); written = fwrite( dfile, mem, size ); if( size != written ) goto cleanup; >while( size ) ret = TRUE; cleanup: // Аналог деструктора. if( sfile) fclose( sfile ); if( dfile) fclose( dfile ); if( mem ) free( mem ); return ret; // Ожидаемая ошибка. >
BOOL Copy( CHAR* sname, CHAR* dname, OUT HANDLE* error ) < HANDLE sfile = 0, dfile = 0, data = 0; UINT32 size = 0; ENSURE( PoolAlloc() ); // Макрос обеспечивает обработку неожиданной ошибки. ENSURE( FileOpen( sname, OUT REQUIRE( SUCCESS( error ) ); // Макрос обеспечивает обработку ожидаемой ошибки. ENSURE( FileOpen( dname, OUT REQUIRE( SUCCESS( error ) ); ENSURE( MemAlloc( OUT REQUIRE( SUCCESS( error ) ); do < ENSURE( FileRead( sfile, F_CHUNK_SIZE, OUT REQUIRE( SUCCESS( error ) ); ENSURE( FileWrite( dfile, REQUIRE( SUCCESS( error ) ); ENSURE( MemGetSize( OUTwhile( size ); ENSURE( PoolFree() ); // Пул обеспечивает аналог деструкторов и RAII. return TRUE; >
Через некоторое время разработчики заметили, что большинство успешных решений использует ООП и решили что неплохо бы его вынести в синтаксис языка, дабы писать больше кода по делу и меньше — повторяющегося кода для поддержки архитектуры.
Что стало после введения исключений
Давайте возьмем код выше и посмотрим, как он трансформировался после добавления ООП в синтаксис языков программирования. Конструирование и уничтожение объектов (fopen, fclose) стало конструкторами и деструкторами. Переброс неожиданной ошибки (BOOL ret в первом примере, макрос ENSURE во втором) однозначно стал исключением.
А вот с ожидаемой ошибкой случилось самое интересное — случился выбор. Можно было использовать возвращаемое значение — теперь, когда заботу о неожиданных ошибках взяли на себя исключения, возвращаемое значение снова стало в полном распоряжении программиста. А можно было использовать исключения другого типа — если функции копирования файлов самой не нужно обрабатывать ожидаемые ошибки то логично вместо if и REQUIRE просто ничего не делать — и оба типа ошибок уйдут вверх по стеку. Соответственно, у программистов снова получилось два варианта:
-
Подход только исключения — ожидаемые и неожиданные ошибки — это разные типы исключений.
void Copy( string sname, string dname ) < file source( sname ); file destination( sname ); source.open( «rb» ); destination.open( «wb» ); data bytes; do < bytes = source.read( F_CHUNK_SIZE ); destination.write( bytes ) >while( bytes.size() ) >
bool Copy( string sname, string dname ) < file source( sname ); file destination( sname ); if( ! source.open( «rb» ) || ! destination.open( «wb» ) ) return false; data bytes; do < bytes = source.read( F_CHUNK_SIZE ); if( bytes.isValid() ) < if( ! destination.write( bytes ) ) return false; >> while( bytes.isValid() bytes.size() ) >
Почему выжили коды возврата?
- Первые реализации исключений, особенно в C++, были не очень удобны для ежедневного использования. Например, бросание исключения во время обработки другого исключения приводил к завершению программы. Или же бросание исключения в конструкторе приводило к тому, что деструктор не вызывался.
- Разработчикам API забыли объяснить для чего нужны исключения. В результате первое время не было даже деления на ожидаемые (checked) и неожиданные (unchecked), а API комбинировали как исключения, так и коды возврата.
- В большинстве языков для исключений забыли добавить семантику «игнорировать ожидаемую ошибку». В результате на практике код, использующий исключения как для ожидаемых так и для неожиданных ошибок, с невероятной скоростью обрастал try и catch везде, где только можно.
Выводы
Что бы я хотел резюмировать. На мой взгляд, большинство проблем с исключениями были вызваны первыми, не очень удачными реализациями — особенно в C++. Так что выбор «использовать только коды возврата», «использовать исключения для неожиданных ошибок и коды возврата для ожидаемых» или «использовать исключения для всего» по большей части имеется только для C++. Надеюсь, мой краткий рассказ о причинах появления исключений в современных языках программирования поможет разработчикам чуть лучше ориентироваться в современных API и замечать места, где авторы использую исключения некорректно. Понимание какие из ошибок мы считаем для нашей программы ожидаемыми, какие — неожиданные и как это оптимальным образом ложится на предоставляемую языком и API модель исключений позволяет писать простой, понятный и внимательно следящий за ошибками код.
Источник: habr.com
Пакетный скрипт – Код возврата
По умолчанию, когда выполнение командной строки завершено, оно должно либо возвращать ноль, если выполнение завершается успешно, либо ненулевое, если выполнение не выполняется. Когда пакетный скрипт возвращает ненулевое значение после сбоя выполнения, ненулевое значение будет указывать, что такое номер ошибки. Затем мы будем использовать номер ошибки, чтобы определить ее причину и соответствующим образом ее устранить.
Ниже приведены общий код выхода и их описание.
Недостаточно виртуальной памяти.
Это указывает на то, что в Windows не хватает памяти.
Недостаточно виртуальной памяти.
Это указывает на то, что в Windows не хватает памяти.
Уровень ошибки
Переменная среды% ERRORLEVEL% содержит код возврата последней выполненной программы или сценария.
По умолчанию способ проверки на наличие ОШИБКИ находится через следующий код.
Синтаксис
IF %ERRORLEVEL% NEQ 0 ( DO_Something )
Обычно используется команда EXIT / B% ERRORLEVEL% в конце пакетного файла, чтобы вернуть коды ошибок из пакетного файла.
EXIT / B в конце командного файла остановит выполнение командного файла.
Используйте EXIT / B в конце пакетного файла для возврата пользовательских кодов возврата.
Переменная среды% ERRORLEVEL% содержит последний уровень ошибки в пакетном файле, который является последними кодами ошибок из последней выполненной команды. В пакетном файле всегда рекомендуется использовать переменные среды вместо постоянных значений, поскольку одна и та же переменная расширяется до разных значений на разных компьютерах.
Давайте посмотрим на быстрый пример того, как проверить коды ошибок из командного файла.
пример
Давайте предположим, что у нас есть пакетный файл с именем Find.cmd, который имеет следующий код. В коде мы четко упомянули, что если мы не найдем файл lists.txt, то должны установить уровень ошибки равным 7. Точно так же, если мы видим, что переменная userprofile не определена, мы должны установить код уровня ошибки на 9.
if not exist c:lists.txt exit 7 if not defined userprofile exit 9 exit 0
Давайте предположим, что у нас есть еще один файл с именем App.cmd, который сначала вызывает Find.cmd. Теперь, если Find.cmd возвращает ошибку, в которой он устанавливает уровень ошибки больше 0, он завершает работу программы. В следующем пакетном файле после вызова Find.cnd он на самом деле проверяет, не превышает ли уровень ошибки больше 0.
Call Find.cmd if errorlevel gtr 0 exit echo “Successful completion”
Выход
В приведенной выше программе мы можем использовать следующие сценарии:
- Если файл c: lists.txt не существует, в выводе консоли ничего не будет отображаться.
- Если переменная userprofile не существует, в выводе консоли ничего не будет отображаться.
- Если оба вышеуказанных условия выполнены, в командной строке будет отображена строка «Успешное завершение».
Если файл c: lists.txt не существует, в выводе консоли ничего не будет отображаться.
Если переменная userprofile не существует, в выводе консоли ничего не будет отображаться.
Если оба вышеуказанных условия выполнены, в командной строке будет отображена строка «Успешное завершение».
Loops
В главе, посвященной принятию решений, мы увидели утверждения, которые последовательно выполнялись одно за другим. Кроме того, реализации также могут быть выполнены в пакетном скрипте, чтобы изменить поток управления в логике программы. Затем они классифицируются в поток контрольных операторов.
В Batch Script нет прямого оператора while, но мы можем очень легко реализовать этот цикл, используя оператор if и метки.
Конструкция «FOR» предлагает возможности зацикливания для пакетных файлов. Ниже приведена общая конструкция оператора for для работы со списком значений.
Оператор for также может перемещаться по диапазону значений. Ниже приводится общая форма заявления.
Ниже приводится классический оператор for, который доступен в большинстве языков программирования.
В Batch Script нет прямого оператора while, но мы можем очень легко реализовать этот цикл, используя оператор if и метки.
Конструкция «FOR» предлагает возможности зацикливания для пакетных файлов. Ниже приведена общая конструкция оператора for для работы со списком значений.
Оператор for также может перемещаться по диапазону значений. Ниже приводится общая форма заявления.
Ниже приводится классический оператор for, который доступен в большинстве языков программирования.
Цикл по аргументам командной строки
Оператор ‘for’ также можно использовать для проверки аргументов командной строки. В следующем примере показано, как можно использовать оператор for для циклического перебора аргументов командной строки.
пример
Выход
Давайте предположим, что приведенный выше код хранится в файле с именем Test.bat. Приведенная выше команда выдаст следующий вывод, если командный файл передает аргументы командной строки 1,2 и 3 как Test.bat 1 2 3.
1 2 3
Оператор break используется для изменения потока управления внутри циклов в любом языке программирования. Оператор break обычно используется в конструкциях цикла и используется для немедленного завершения самого внутреннего замкнутого цикла.
Источник: coderlessons.com