Неочевидный дизайн enum в C#

Недавно столкнулся с задачей сконвертировать строковое значение в Enum. В строке может быть как нормальное строковое значение из перечисления, так и число.
Задачка тривиальная:
- Вызываем Enum.TryParse(value, out var result)
- Если распарсили - используем это значение дальше
- Если нет - выполняем логику обработки отсутствия значения в enum

И тут на вход прилетает строковое значение "333" (такого значения в enum нет). А TryParse возвращает true. Итог - некорректное поведение системы. И нет, это не баг - это стандартное поведение метода TryParse.

Лично для меня супер неочевидно то, что TryParse не проверяет соответствие числа именованной константе из enum . Теперь знаю, что такое поведение исправляется с помощью метода IsDefined. (Источник - https://github.com/microsoft/referencesource/blob/master/mscorlib/system/enum.cs#L367)

А вот пример для воспроизведения:

var value = "333";
        
Console.WriteLine($"Пытаемся распарсить: '{value}'");

if (Enum.TryParse<SomeEnum>(value, out var result))
{
    Console.WriteLine($"Результат парсинга - '{result}'. Тип - '{result.GetType().Name}'");
}
else
{
    Console.WriteLine("Распарсить значение не удалось");
}
public enum SomeEnum
{
    FirstValue = 0,
    SecondValue = 1
}

Что интересно: в java и kotlin такого поведения не замечено (беглым тестом в онлайн компиляторе). В typescript тоже - при парсинге из числа, которое не входит в enum мы получаем undefined. Интересно, какие причины такой реализации?

#кейсы

{"query": {"bool": {"must": [{"nested": {"path": "nested_field","query": {"bool": {"must": [{ "match": { "nested_field.field1": "value1" }},{ "match": { "nested_field.field2": "value2" }}]}} }},{ "range": { "date_field": { "gte": "2024-01-01", "lte": "2024-02-01" }}}],"should": [{ "term": { "should_field": "value3" }},{ "term": { "should_field": "value4" }}]}}}. Как вам такое? Читаемо? Понятно? Это запрос в elasticsearch, причём не самый большой и сложный. С подобными огромными джейсонами без форматирования я сталкиваюсь очень часто. А ещё их часто надо сравнивать. А ещё я иногда использую регулярки. Есть тонна сайтов, которые решают каждую из этих проблем по отдельности, но это не очень удобно. У некоторых бесит дизайн, сами эти сайты нужно выискивать и добавлять в закладки...

Да, это снова рекомендации по приложениям. На этот раз - DevToys - мультитул разработчика. Очень удобная штука, которую использую как в работе, так и в пет-проектах.

Мои основные кейсы:
- Форматирование JSON (или XML) - часто из дебага вытаскиваю огромные запросы эластика и монги, и надо их раскрыть и проанализировать. Копирую огромный JSON, вставляю в DevToys - получаю читаемый текст. Много проблемных запросов обнаружил как раз благодаря этому инструменту
- Сравнение текстов - снова пример с запросами в БД. Допустим, есть баг - на продакшн среде и на тестовой среде разное поведение. Беру запрос с прода, с теста и сравниваю. Или просто какие-то тексты, результаты от API, и прочее - всё, что нельзя или неудобно сравнивать через гит
- Проверка регулярных выражений - иногда пользуюсь сайтом regex101, иногда этим приложением

В зависимости от задач и специфики работы могут пригодиться совершенно разные функции этого приложения. Думаю, что оно будет полезно не только разработчикам, но и аналитикам, тестировщикам и многим другим. В общем, пробуйте!
#приложения
Flex Code

Скоро выступим!

https://t.me/exoz_tech/154

Выступление прошло вполне успешно! Конечно, есть над чем работать (как обычно), но в целом я доволен.

Чуть позже выложу презентацию и другие материалы)

Итак, утро начинается с блокировки российских айпишников Docker Hub

Во-первых, тут в комментах есть разные варианты настроек зеркал (а ещё срачи!)

А ещё порадовал наш ответ - https://huecker.io/ ))) Не знаю, насколько надёжно использовать именно его в качестве прокси, но инструкция там удобная и есть адрес других проксей

1. Введение в Elastic
2. Разворачиваем Elasticsearch
3. CRUD-операции в Elasticsearch
4. Как Elasticsearch обрабатывает текст?
5. Странности Ограничения Elasticsearch и Email (вы здесь)


Странности Ограничения Elasticsearch и Email

Как мы знаем из предыдущего поста - у эластика есть различные встроенные токенизаторы. Один из них - uax_url_email_tokenizer, который работает как стандартный, но при наличии в тексте адреса электронной почты, выделяет его в отдельный токен. Например:
- Результат стандартной токенизации: [ Email, me, at, john.smith, global, international.com ]
- Результат токенизации uax_url_email: [ Email, me, at, john.smith@global-international.com ]

В одной из систем, над которой я работал, был использован этот токенизатор для полнотекстового поиска по пользователям. И всё было прекрасно, пока не пришли... локальные домены верхнего уровня.

Домены верхнего уровня - это те самые .ru, .com и т.д. А в локальной сети их можно назначить самостоятельно, например .qwe и использовать. Ну, кто-то их и использовал, и у нас сломался поиск по пользователям. Почему сломался? Непонятно. Адреса просто разбивались как в примере со стандартным механизмом. Документация нам ответа не дала...

Поэтому идём в исходники
- Поиск по исходному коду эластика привёл к UAX29URLEmailTokenizerFactory, который просто возвращает new UAX29URLEmailTokenizer(). Судя по импортам в файле, он находится в Lucene. Направляемся туда.
- В файлах с реализацией UAX29URLEmailTokenizer ориентироваться довольно тяжело. Они созданы с помощью утилиты jflex, которая генерирует код на основе указанных спецификаций в специальных файлах. Тут нас интересует файл ASCIITLD.jflex, который содержит выражения для всех доменов на основе базы данных глобального регистратора IANA. На основе этих доменов elastic определяет: это собственно часть домена в адресе почты или просто строка. И в этой базе нет различных кастомных доменов, например "qwe", и никак их туда не добавить...

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

Flexible Coding