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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не согласен

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

Стикер

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

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

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

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

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

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

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

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

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

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

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

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

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

иногда причина твоих ошибок неочевидна. А рядом никаких поясняющих надписей нет. А кнопка "ок" недоступна, несмотря на многочисленные попытки. Какие при этом выражения в адрес разработчика звучат, догадываешься? :)

Так кто мешает пояснения выводить?

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

Док, просто надо ООП применять, а не всё в рукопашную преодолевать )

Коль, ты умными словами не разговаривай. Ты пальцем покажи 😁

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

Неа, потому что хинт рассказывает. Или в доке описано.

Коль, сложно еще и это через ООП реализовывать. Это ж какие мозги надо иметь :) Тогда уж проще в OnKeyPress или OnExit/OnEditionDone контроллировать вводимые/введенные данные

Именно поэтому это и делается, потому что, слышать косвенные маты через 3 лиц и невнятные багрепорты, которые оными не являются, намного проблемные.

Леш, кто ж в современным мире доки читает? О чем ты? :))))

Нифига это не сложно ) Там внутри я на эти события и вешаю обработчики уже готовые )

не гибко. И Оккама против. Понадобится тебе изменить условия в обработчике, опять интерфейс писать?

А у меня прописано так, что назначенные на форме обработчики не перезатираются

Но хинт или (?) Вопросик можно посмотреть. Я пишу минимальные требования к квалификации. Инструкции по применению. И если оператор неумный, у меня жопа прикрыта. "Рекомендации лучших собаководов."