В отличие от int, тип unsigned int может хранить только положительные целые числа.

В языке Dart нет такого понятия как unsigned int, в то время как в языке go есть возможность использовать данные числовые типы (uint8 , uint16 , uint32 , uint64).

В языке proto3 тоже есть возможность использования uint32 и uint64.

Я решил провести эксперимент и сделать клиент на Dart, сервер на go, и попробовать отправить отрицательные значения в полях предназначенных для uint32 и uint64.

Сейчас представлю четыре варианта потенциального исхода (что же произойдет если отправить -1 или -9223372036854775808 в поле предназначенном для uint)?

Как вы думаете, что произойдет в данном случае?

  1. gRPC плагин на Dart не соберет файлы для клиента

  2. При отправке сообщения возникнет ошибка

  3. Сообщение c числом x будет отправлено, сервер интерпретирует его как 0

Любопытные могут посмотреть ответ в конце статьи. А я расскажу о том, как проводился сам эксперимент.

Шаг 1 - пишем необходимый для теста proto файл.

Определяем тип синтаксиса, пакеты, сервис и заветное сообщение содержащие положительные int.

Шаг 2 - Делаем пустое приложение dart, go, генерируем код для grpc и добавляем зависимости

Для всех этих действий нужен следующий ряд команд:

  • dart create console-full

  • protoc some/folder/api.proto --dart_out=grpc:.

  • protoc other/folder/api.proto --go-grpc_out=. --go_out=.

  • dart pub add fixnum

  • dart pub add protobuf

  • dart pub add grpc

  • go mod tidy

Шаг 3 - Пишем сервер на го

Шаг 4 - Пишем клиент на dart

Шаг 5 - проверяем

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

Запускаем сервер, клиента и получаем:

Ошибка содержит следующий текст:

Illegal to set field first (3) of api.Inp to value (-1): out of range for unsigned 32-bit int

Что означает, что ошибка типа была обнаружена в рантайме.

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

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

Комментарии (3)


  1. micbal
    21.12.2021 09:14
    +4

    Зачем код размещать в виде картинок?


  1. ertaquo
    21.12.2021 09:45
    -2

    Эмм... А про что, собственно, статья? Как подать на вход некорректное значение и словить ошибку?


  1. OkunevPY
    21.12.2021 23:23

    Очень интерестно к чему это?

    Ну сложили число в число, ну словили ошибку, какого результата ждали то?