Недавно я экспериментировал с хранимыми процедурами JavaScript Snowflake и столкнулся с неожиданным поведением. Я создал простую хранимую процедуру, как описано в документации Snowflake здесь.
Вот созданная мной хранимая процедура:
create procedure broken()
returns varchar not null
language javascript
as
$$
var result = "";
try {
snowflake.execute( {sqlText: "Invalid Command!;"} );
result = "Succeeded";
}
catch (err) {
result = "Failed: Code: " + err.code + "\n State: " + err.state;
result += "\n Message: " + err.message;
result += "\nStack Trace:\n" + err.stackTraceTxt;
}
return result;
$$
;
Целью этой хранимой процедуры является преднамеренный сбой путем выполнения недопустимой команды SQL и последующий перехват ошибки с помощью блока try-catch.
Когда я вызываю хранимую процедуру, она действительно возвращает ожидаемое сообщение об ошибке, указывающее на сбой:
call broken();
Выход:
+---------------------------------------------------------+
| BROKEN |
|---------------------------------------------------------|
| Failed: Code: 1003 |
| State: 42000 |
| Message: SQL compilation error: |
| syntax error line 1 at position 0 unexpected 'Invalid'. |
| Stack Trace: |
| Snowflake.execute, line 4 position 20 |
+---------------------------------------------------------+
Однако, проверив историю запросов Snowflake, я заметил, что эта процедура отмечена как успешное выполнение. Это кажется противоречивым, поскольку процедура явно нацелена на провал. Я ожидаю, что это будет помечено как неудачное выполнение.
Может ли кто-нибудь пролить свет на то, почему Снежинка считает эту попытку успешной, несмотря на ожидаемый провал? Существует ли другой подход для обработки таких сценариев и обеспечения правильного отражения неудачных выполнений хранимых процедур в истории запросов? Любые идеи или предложения будут с благодарностью приняты. Спасибо!
возврат строки «I HAVE FAILED» — это успех, потому что это произошло, тогда как на самом деле произошел сбой:
create procedure actual_failure()
returns varchar not null
language javascript as
$$
snowflake.execute( {sqlText: "Invalid Command!;"} );
return "Succeeded";
$$
;
затем
call actual_failure();
на самом деле терпит неудачу.
Мне также нужно проверить, работает ли этот фактический сбой, если у вас есть родительский процесс хранения, который вызывает множество дочерних процессов хранения. Моя цель состоит в том, чтобы родительские процессы хранилища терпели неудачу, если один из дочерних процессов хранилища терпел неудачу.
да, если вы остановите его провал, он не провалится. НО, если вы хотите отловить сбой, вставить строку в таблицу журнала, а затем разобрать ее, чтобы «вся процедура завершилась неудачно», у вас уже есть все необходимое для этого.
Как уже упоминали другие, «ловушка» обрабатывает ошибку, поэтому ваш процесс в целом больше не ошибается. Если вы хотите, чтобы ваш родительский процесс распознавал ошибку процесса, даже если вы обработали ошибку в блоке «catch», тогда ваш «catch» должен выдать ошибку – используя команду «throw», например бросить (результат);
Я попробовал бросить, все равно получилось
Итак, вы говорите, что у вас не может быть одновременно попытки и фактической неудачи? Потому что в конечном итоге попытка catch возвращает «успех».