У меня это всегда вопрос вызывало.. Нафига писать код так,

чтобы потом ошибки вылавливать?

Данные приходят снаружи. Валидность их не гарантирована

Будь добр не тэгать мои сообщения

Ты какой-то особенный? Я нормально общаюсь без задних мыслей. Не агрись на пустом месте

@Renat_Suleymanov я вежливо пытаюсь оградить себя от общения с данным товарищем

Он же тебя вообще никак не задевают. Какие сейчас то претензции?

Много компонентов использует этот механизм. Хочешь не хочешь, но обрабатывать это как-то надо

Надо не ограждаться а общаться нормально и все будет ок

Я попросил его не тэгать мои сообщения. Вежливо. Мне неприятно общение с ним, но функционал телеграма не позволяет заблокировать его в общих чатах.

Я тебе вежливо отказал. Это общий чат

Просто надо ввод данных контролировать, а не разгребать потом ошибки ввода. Это моё мнение.

Зачем делать работу, которую уже сделали? Если вылетает EConvertError, значит неправильно значение, вот и всё

Исключение - это катапульта. Ты же выходишь из машины, штатно, через дверь?

Не согласен

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

Стикер

Ok. Но есть 2 крайности: - Безопасный,(Try{Convert}. SUCCEED, GetLastError) - И Exception Based. Это крайности, повторюсь. Но ты наверняка начинал, когда исключения уже были. Потому так и говоришь. Не делю на черное и белое. Использую. Можно без исключений - лучше без них. В Go их, именно потому и не стали делать.

Там можно себе наваять класс-хэлпер с кучей плюшек и не париться потом написанием кучи кода для обработки исключений

Не, если есть безопасный метод Try*, то конечно. Но всё это зависит от задачи и от того, что требуется получить. Например, если у тебя метод требует чтения значения из конфига и не допускает дефолтного значения, то нет смысла использовать Try* и сразу выдать исключение, что нет значения - работать дальше нельзя

Это... дорого. Зачем давать пользователю вводить неверные данные? Когда можно не давать вводить фигню, как пример. И в худшем случае получать отлуп от базы и откатывать транзакцию.

Тут можно маскировку ошибок ввода получить просто на раз и потом на другом совершенно уровне закопаться в разруливании последствий

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

Я пришел к схеме, когда кнопка OK/Save просто не доступна, если данные невалидны. И поля ввода, неправильные, подсвечиваются. Пользователи тупые, надо любить и помогать маленьким неумехам.

Это один из подходов. Я просто запрещаю дальнейшую обработку, пока не будут указаны корректные значения

Валидность это не просто правильный ввод. Это более широкое понятие

Боюсь ты не понял... Ошибка уже совершена. Ты борешься с последствиями. А надо бороться с причиной и до этого не доводить. Форма ввода уже может быть разрушена к тому моменту. А если ты сохраняешь там, то ССЗБ. Эти выводы/подход получился не просто потому что "хочу так", а потому что по другому писанины много больше, код и логика сложнее.

Спасибо, Кэп! Но дальше - то что? Если можно снизить уровень бардака в этом конкретном месте, то почему это не сделать? Тем более, если это делает жизнь проще.

Я к тому что бардак всеравно будет просачиваться и как тут выше рекомендуют я всё проверю, а потом на проверки тратиться небуду - в общем случае невыполнимо

Ну мы же не знаем, что под капотом у функций, передающих ошибку в GetLastError, может там тоже своеобразная система исключений. По сути так и есть, мы пишем в лог и выходим из функции, это внешне кажется, что разные механизмы