Неудачное веб-задание из очереди хранилища Azure не записывается в Poison Queue

У меня есть веб-задание Azure, которое обрабатывает новые элементы в очереди хранилища Azure. Это работает. Я установил для MaxDequeueCount низкое значение, и после того, как операция, запускаемая очередью, терпит неудачу столько раз, я ожидаю, что этот элемент в очереди будет перемещен в опасную очередь.

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

 public static async Task ProcessQueueMessage([QueueTrigger("myQueue")] CloudQueueMessage message, TextWriter log)
    {
        try
        {
            throw new InvalidCastException();          
        }
        catch (Exception exception)
        {
            log.WriteLine($"Exception in ProcessQueueMessage: {exception}");
            throw;
        }
    }

person user1060500    schedule 17.06.2019    source источник
comment
Код вашей функции не вызывает сбоев при обработке сообщения. Он завершает обработку с успешной обработкой исключения. Вы либо решаете не обрабатывать исключение, либо повторно генерируете исключение из блока catch после регистрации сообщения.   -  person Chetan Ranpariya    schedule 17.06.2019
comment
Как же так? если вы внимательно посмотрите на блок catch, он выбрасывает исключение.   -  person user1060500    schedule 17.06.2019
comment
Он генерирует исключение ... но также обрабатывает исключение ... вы не повторно генерируете это из блока catch ... если вы обрабатываете исключение, а не повторно генерируете его, это означает, что вы знаете об исключении и убедитесь, что все хорош даже после исключения, это означает, что при обработке сообщений не возникло никаких проблем ...   -  person Chetan Ranpariya    schedule 17.06.2019
comment
Ты неправ. Там есть заявление о броске, но я думаю, вы не присмотрелись после того, как я сказал вам в первый раз. (посмотрите на конец строки в блоке catch)   -  person user1060500    schedule 17.06.2019
comment
@ user1060500 - это случай, когда вам следует подумать о правильном форматировании кода, чтобы в конце строки не было символа throw. Без прокрутки окна кода его невозможно увидеть (но вы, кажется, расстроены тем, что люди не ищут внимательно то, что совсем не очевидно). И вам пришлось сделать несколько комментариев по этому поводу, включая комментарий к опубликованному ответу. (к сведению, я отредактировал это, чтобы оно было правильно отформатировано)   -  person David Makogon    schedule 17.06.2019
comment
Спасибо за урок. В Visual Studio это две отдельные строчки. По какой-то причине он был добавлен в одну строку, когда я поместил его в StackOverflow. Спасибо за редактирование. Я даже не думал, что для большинства экранов потребуется горизонтальная прокрутка. На моем старом мониторе я отчетливо вижу это от начала до конца ... (для записи, не расстраиваюсь и не волнуюсь. Просто предоставляю объективную информацию и ищу помощь с этой проблемой - если вы можете что-то предоставить, пожалуйста, дайте мне знать )   -  person user1060500    schedule 17.06.2019
comment
Я тестирую на своем сайте, и он работает хорошо и может отправить сообщение в очередь подозрений. Не могли бы вы показать мне более подробную информацию, например, ваш sdk-файл webjob и версию хранилища?   -  person Joey Cai    schedule 17.06.2019


Ответы (1)


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

person Kamran    schedule 17.06.2019
comment
(посмотрите на конец строки в блоке catch) - person user1060500; 17.06.2019
comment
Как насчет того, чтобы использовать вместо этого следующее. бросить новое исключение (); - person Kamran; 18.06.2019