PL SQL - возвращать SQLCODE как параметр OUT принят? - PullRequest
Новая
       33

PL SQL - возвращать SQLCODE как параметр OUT принят?

2 голосов
/ 21 декабря 2009

У меня есть процедура, которая возвращает параметр OUT. 

procedure foo (in_v IN INTEGER, out_v OUT integer)
BEGIN
...
EXCEPTION
  WHEN OTHERS THEN
    --sh*t happend
    out_v := SQLCODE;
END

Этот параметр будет 0, если все идет хорошо, и <> 0, если что-то случилось.

Теперь, если по пути произойдет sh * t, будет сгенерировано исключение.

Можно ли присвоить значение SQLCODE параметру OUT? Или это связано с запахом кода, и я буду исключен из сообщества программистов?

Заранее спасибо.

Ответы [ 4 ]

11 голосов
/ 21 декабря 2009

Если нет дополнительной обработки ошибки, я бы, вероятно, посоветовал против нее. Этот подход просто заставляет каждого вызывающего абонента все равно проверять значение параметра out. И если вызывающий забывает об этом, серьезная проблема может сначала остаться незамеченной и создать трудную для отладки проблему в другом месте.

Если вы просто не перехватываете здесь ДРУГОЕ, вы гарантируете, что вызывающая сторона должна явно его перехватить, что намного чище и легче в отладке.

4 голосов
/ 21 декабря 2009

Неважно, нормально это или нет, я полагаю, что вы пытаетесь достичь с ним. Какую проблему вы пытаетесь решить, или какое требование вы пытаетесь выполнить?

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

2 голосов
/ 21 декабря 2009

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

Если вы решите пойти по этому маршруту, также передайте обратно SQLERRM, поскольку без текста ошибки у вас есть только код ошибки, по которому нужно пройти. После многих лет обнаружения «-20001» для сотен ошибок приложений в стороннем программном обеспечении SQLERRM часто важен.

0 голосов
/ 07 января 2010

Этот стиль кодирования не является хорошей идеей по ряду причин.

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

Второй тревожный аспект стиля кодирования заключается в том, что ваш код фактически говорит, что при обнаружении исключения код сообщит вызывающей стороне, что произошло что-то плохое, но с радостью выбросит ВСЕ сведения об исключениях, кроме SQLCODE. 1005 *

...