Как я могу заставить serde выдавать поля, которые не удалось проанализировать в выводе ошибки?

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

Другими словами, ошибка serde не сообщает мне, какое поле не удалось проанализировать в допустимом JSON. Как я могу это сделать?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8d9e8f8d97626916873b10a3ea780449

Если вы признаете ошибки, то это как бы говорит, откуда они. Это chrono ошибка. Поскольку "2024-1-1" является Date, а не DateTime, его анализ как DateTime приводит к ошибке premature end of input. Есть различные способы обойти это. В целом, если вы хотите больше описательных ошибок, вам нужно использовать deserialize_with, а затем map_err() для создания более описательных ошибок.

vallentin 12.04.2024 02:23

На самом деле это полностью говорит вам, откуда возникает ошибка. На вашей игровой площадке это строка 1, столбец 19, т. е. в конце строки "2024-1-1".

Jmb 12.04.2024 09:00

@jmb, отсюда понятно, откуда это взялось, потому что создал репозиторий MVP. Фактическая полезная нагрузка, о которой идет речь, легко имела глубину 5 уровней и более 100 полей. Мой вопрос не в том, «почему это не удается», а в том, «как я могу заставить serde сообщить мне, какое поле не удалось проанализировать».

cdaringe 12.04.2024 19:37

Это не имеет ничего общего с тем, что это MRE, а связано с сообщением об ошибке Serde: «Ошибка («Преждевременное завершение ввода», строка: 1, столбец: 19)». В вашей реальной полезной нагрузке вы можете получить огромные номера строк/столбцов, но любой приличный текстовый редактор способен перейти к заданной позиции и показать вам не только поле, вызвавшее ошибку, но и фактический символ, в котором произошла ошибка.

Jmb 15.04.2024 08:53

В нашем случае строка/столбец всегда означала конец полной полезной нагрузки верхнего уровня. Строка/столбец не представляла достоверной информации в реальной коллекции структур.

cdaringe 18.04.2024 18:10
Почему Python в конце концов умрет
Почему Python в конце концов умрет
Последние 20 лет были действительно хорошими для Python. Он прошел путь от "просто языка сценариев" до основного языка, используемого для написания...
1
5
92
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

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

Вы можете использовать serde_path_to_error, чтобы добавить информацию о местоположении к любой ошибке десериализации.

(Сам я им не пользовался, но видел, что его рекомендовали, и он написан тем же автором, что и сам сериал, Дэвидом Толнаем.)

Это кажется хорошим решением. Спасибо за ссылку!

cdaringe 12.04.2024 21:31

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