Теперь вы, возможно, думаете, что мы просто создаем новые экземпляры NotificationEmitter по мере необходимости и используем их для каждого контекста. Однако мы собираемся применить несколько иной подход. План состоит в том, чтобы добавить инициализатор к нашему типу процессора, который будет хранить ссылку на эмиттер в качестве переменной экземпляра. Это будет выглядеть так: def initialize(@emitter : Transform::NotificationEmitter = Transform::NotificationEmitter.new); end. Я не буду объяснять причину этого, поскольку она будет рассмотрена в Главе 14 «Тестирование».
Давайте сначала сосредоточимся на обработке контекста ошибки. К сожалению, поскольку jq будет выводить сообщения об ошибках непосредственно на IO, ошибок, мы не сможем их обработать. Однако мы можем обрабатывать реальные исключения из нашего кода Crystal. Поскольку мы хотим обрабатывать любые исключения, возникающие в нашем методе #process, мы можем использовать короткую форму для определения блока rescue:
rescue ex : Exception
if message = ex.message
@emitter.emit "Oh no!", message
end
raise ex
Этот код должен располагаться непосредственно под последней строкой каждого метода, но перед закрывающим тегом метода. Этот блок спасет любое исключение, возникшее в методе. Затем он отправит уведомление с сообщением об исключении в качестве тела уведомления. Не все исключения имеют сообщение, поэтому мы обрабатываем этот случай, проверяя его перед отправкой уведомления. Наконец, мы повторно вызываем исключение.
В случае с методом #process_multiple нам нужно будет немного улучшить наш код параллелизма, чтобы лучше поддерживать обработку исключений. Хорошей практикой считается обработка любых исключений, возникающих в волокне, внутри самого волокна.
К сожалению, на данный момент работа с каналами и волокнами находится на несколько более низком уровне, чем хотелось бы в идеале. Есть несколько выдающихся предложений, например https://github. com/crystal-lang/crystal/issues/6468, но в стандартной библиотеке еще не реализовано ничего, что позволяло бы использовать некоторые встроенные абстракции или API более высокого уровня. С другой стороны, проблема, которую мы хотим решить, довольно тривиальна.
В последней главе мы добавили отправку с использованием блока ensure для корректной обработки контекстов сбоя, но упомянули, что эта реализация не идеальна, главным образом потому, что мы хотим иметь возможность различать контексты успеха и неудачи. Чтобы решить эту проблему, мы можем изменить канал, чтобы он принимал объединение Bool | Exception вместо просто Bool. Затем, снова используя короткую форму rescue, мы можем отправить каналу возникшее исключение, заменив блок ensure. В конечном итоге это будет выглядеть так:
channel.send true
rescue ex : Exception
channel.send ex
Подобно другим блокам восстановления, этот также будет идти сразу после channel.send true, но перед конечным тегом блока spawn. Затем нам нужно обновить логику получения для обработки значения исключения, поскольку в данный момент мы всегда игнорируем полученное значение. Для этого мы обновим цикл, чтобы проверить тип полученного значения, и поднимем его, если это тип Exception:
input_args.size.times do
case v = channel.receive
in Exception then raise v
in Bool
# Skip
end
end
Теперь, когда мы вызываем исключение из волокна внутри самого метода, наш блок восстановления в методе теперь будет вызываться правильно. Полный метод #process_ multiple находится в папке главы на GitHub: https://github.com/PacktPublishing/Crystal-Programming/blob/main/ Chapter07/process_multiple.cr.
Я обнаружил, что самый простой способ протестировать нашу логику отправки уведомлений — это передать файл, который не существует в режиме нескольких файлов. Например, запустив ./bin/transform -m .random-file.txt должен привести к отображению уведомления, информирующего вас о том, что при попытке открыть этот файл произошла ошибка.
Резюме
Увы, мы подошли к завершению нашего проекта CLI. За последние четыре главы мы значительно улучшили приложение. В процессе работы мы также расширили наши знания о различных концепциях Crystal. Хотя это и конец этой части книги, это не обязательно должен быть конец CLI. Не стесняйтесь продолжать самостоятельно, добавляя функции по своему желанию. В конечном счете, это поможет закрепить концепции, представленные на этом пути.