Хранимая процедура Snowflake JavaScript возвращает успех, несмотря на ожидаемый сбой

Недавно я экспериментировал с хранимыми процедурами 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, я заметил, что эта процедура отмечена как успешное выполнение. Это кажется противоречивым, поскольку процедура явно нацелена на провал. Я ожидаю, что это будет помечено как неудачное выполнение.

Может ли кто-нибудь пролить свет на то, почему Снежинка считает эту попытку успешной, несмотря на ожидаемый провал? Существует ли другой подход для обработки таких сценариев и обеспечения правильного отражения неудачных выполнений хранимых процедур в истории запросов? Любые идеи или предложения будут с благодарностью приняты. Спасибо!

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
В настоящее время производительность загрузки веб-сайта имеет решающее значение не только для удобства пользователей, но и для ранжирования в...
Безумие обратных вызовов в javascript [JS]
Безумие обратных вызовов в javascript [JS]
Здравствуйте! Юный падаван 🚀. Присоединяйся ко мне, чтобы разобраться в одной из самых запутанных концепций, когда вы начинаете изучать мир...
Система управления парковками с использованием HTML, CSS и JavaScript
Система управления парковками с использованием HTML, CSS и JavaScript
Веб-сайт по управлению парковками был создан с использованием HTML, CSS и JavaScript. Это простой сайт, ничего вычурного. Основная цель -...
JavaScript Вопросы с множественным выбором и ответы
JavaScript Вопросы с множественным выбором и ответы
Если вы ищете платформу, которая предоставляет вам бесплатный тест JavaScript MCQ (Multiple Choice Questions With Answers) для оценки ваших знаний,...
1
0
243
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

возврат строки «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 возвращает «успех».

mas 03.04.2024 02:23

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

mas 03.04.2024 02:25

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

Simeon Pilgrim 03.04.2024 02:26

Как уже упоминали другие, «ловушка» обрабатывает ошибку, поэтому ваш процесс в целом больше не ошибается. Если вы хотите, чтобы ваш родительский процесс распознавал ошибку процесса, даже если вы обработали ошибку в блоке «catch», тогда ваш «catch» должен выдать ошибку – используя команду «throw», например бросить (результат);

NickW 03.04.2024 13:38

Я попробовал бросить, все равно получилось

mas 04.04.2024 02:06

Другие вопросы по теме