Что значит, “не заставляют”? Это как не обязательность прописки регистрации по месту жительства. Она не обязательна, но без нее много чего сделать не получится.
У всех есть или может быть крыша,а АО не является структурным подразделением ФСБ. То, что по иску будет пук, я не сомневаюсь, но это не отменяет возможности подачи иска или хотя бы заявления в Прокуратуру.
О, кстати! Можно и в ФСБ заявление написать, или куда там нужно, что АО Телега предоставляет доступ к заблокированной информации в обход средств контроля трафика (раз она позволяет читать информацию в Телеграме) :-)
Сходное до степени смешения названия и логотипы, направленные на введение пользователя в заблуждение о связи между двумя разными продуктами.
Насчет неправомерного использования торговых знаков должен возмущаться их владелец, а вот насчет введения в заблуждение может быть инициирована и обычным пользователем.
Кроме этого у них в лицензии https://telega.me/privacy есть ссылки на оригинальный мессенджер и другие очень интересные пункты:
1.7 Весь Контент обрабатывается правообладателем Telegram на Условиях Telegram. Лицензиар не обрабатывает (в том числе не хранит) информацию Пользователя, включая данные о чатах, контакты и любой другой Контент Пользователя.
Но это неправда (и обрабатывает и хранит). К тому же данное утверждение противоречит следующему пункту:
1.8 Обработка персональных данных осуществляется Оператором на территории Российской Федерации.
Но ведь оператор обрабатывает данные и сам и за счет использвания оригинального Телеграма, а он точно не в России.
А о какой “уязвимости” тут идет речь, если это явный скам, мошенничество и введение в заблуждение с рекламой несуществующих возможностей у товара(услуги)? Хотя это не исключает потенциальные проблемы у автора, раз он вскрыл подобную тему. Может все таки и должно быть? :-)
По хорошему, подобная информация является основанием для возбуждения уголовного дела против АО «Телега» и это не только из-за неправомерного доступа к компьютерной информации, но и за нарушение закона о рекламе и наверно еще ЗЗПП.
C++ в принципе не может идти по пути Ада, потому что для Ада сперва создавались согласованные требования и только после этого разрабатывался язык и его синтаксис, тогда как в С++ все с точностью наоборот. Сперва сделали С с классами для реализации ограниченного набора идей, а уже после начали на него наворачивать новые концепции, пытаясь их встроить в уже существующий синтаксис.
Если у вас в коде есть ошибка, которую вы не знаете как обработать - кидать исключение - самая глупая идея, которая только может придти вам в голову. Самое разумное в этом случае: немедленно завершить процесс …
Как по мне, так самое глупое, что может сделать программист отдельного компонента (функции, метода или библиотеки), это завершать работу всего приложение, если не знает как обработать в данный момент ошибочную ситуацию.
Использование исключений обязано определяться требованиями, а никак не личными предпочтениями разработчика или его пониманием (или не пониманием) обработки данных.
Я думаю, что он не загнется (ведь ассемблеры существуют до сих пор?). Просто в будущем он займет примерно такую же роль, как сейчас LLVM для генерации машинного кода. Супер универсальный высокоуровневый язык программирования без накладных расходов, но писать на нем вручную можно будет только либо отдельные небольшие фрагменты, либо полностью автоматически генерированный код.
У вас класс принимает бизнес данные в конструктор, а это особенный вызов, который физически не может вернуть информацию об ошибке никаким другим способом, кроме как вызвать исключение.
Делайте или статический фабричный метод или проверяйте данные не в конструкторе, а с помощью обычной функции. Другими словами, прерывания тут совершено не причем.
Данная фраза относится к архитектурным требованиям, которые я считаю разумными. Но вы можете использовать исключения в каких нибудь других вариантах использования. Ведь это обычный инструмент, и как его применять, только ваше дело.
… вот против того, чтобы использовать исключения в качестве механизма возврата любой ошибки, даже не блокирующей, которую надо просто зафиксировать и идти дальше.
Так именно это я и имею ввиду. Исключения нельзя использовать для обработки часто возникающих ситуаций. Их назначение - прерывать поток выполнения при возникновении не восстановимой ситуации, когда становится не важна производительность и требуется корректно обработать завершение приложения. Но если на более высоком уровне есть механизм обработки подобных ситуаций, то пусть он перехватывает исключения и продолжает работу приложения дальше (например вот так Избавляемся от ошибок Segmentation fault из-за переполнения стека в С++).
Другими словами, исключение, это не обработчик ошибок, а возникновение события достаточного для завершения работы всего приложения, но с возможностью его обработки на более высоких уровнях.
К тому же у вас всегда остается возможность просто не перехватывайте исключения. Тогда приложение будет сразу завершаться, что будет полностью соответствовать поведению Rust.
Я не требую использовать исключения в качестве единственного варианта обработки ошибок. Я пишу про то, что в определенных случаях исключения очень удобны, а прерывание выполнения потока команд так или иначе присутствует во всех языках программирования, даже в тех, у которых исключения якобы отсутствуют.
Поэтому лучше иметь стандартизированные исключения с возможностью их обработки в рантайме, чем в каждом случае завершать выполнение приложения по abort или с помощью хаков пытаться реализовывать перехват подобных ошибок.
И каждого варианта свои стандарты, свои компиляторы, возможно свои особенности синтаксиса … И все это должно иметь возможность взаимодействия между сбой. Как представлю, бррр… :-(
Вы в курсе последних принятых и обсуждаемых к принятию законов?
Войти на госуслуги не получалось или был закон, что коды подтверждения должны передаваться только в Whatsapp?
Что значит, “не заставляют”? Это как не обязательность
пропискирегистрации по месту жительства. Она не обязательна, но без нее много чего сделать не получится.Хорошая идея - честно рассказать о выполняемых требованиях и составить конкуренцию обязаловке в виде MAX
У всех есть или может быть крыша,а АО не является структурным подразделением ФСБ. То, что по иску будет пук, я не сомневаюсь, но это не отменяет возможности подачи иска или хотя бы заявления в Прокуратуру.
О, кстати! Можно и в ФСБ заявление написать, или куда там нужно, что АО Телега предоставляет доступ к заблокированной информации в обход средств контроля трафика (раз она позволяет читать информацию в Телеграме) :-)
Сходное до степени смешения названия и логотипы, направленные на введение пользователя в заблуждение о связи между двумя разными продуктами.
Насчет неправомерного использования торговых знаков должен возмущаться их владелец, а вот насчет введения в заблуждение может быть инициирована и обычным пользователем.
Кроме этого у них в лицензии https://telega.me/privacy есть ссылки на оригинальный мессенджер и другие очень интересные пункты:
Но это неправда (и обрабатывает и хранит). К тому же данное утверждение противоречит следующему пункту:
Но ведь оператор обрабатывает данные и сам и за счет использвания оригинального Телеграма, а он точно не в России.
…
и это только с самого начала
А разве АО «Телега» это ФСБ?
А о какой “уязвимости” тут идет речь, если это явный скам, мошенничество и введение в заблуждение с рекламой несуществующих возможностей у товара(услуги)? Хотя это не исключает потенциальные проблемы у автора, раз он вскрыл подобную тему. Может все таки и должно быть? :-)
А оригинальный Телеграм и не нужен, тут достаточно пользователя и АО «Телега»
По хорошему, подобная информация является основанием для возбуждения уголовного дела против АО «Телега» и это не только из-за неправомерного доступа к компьютерной информации, но и за нарушение закона о рекламе и наверно еще ЗЗПП.
C++ в принципе не может идти по пути Ада, потому что для Ада сперва создавались согласованные требования и только после этого разрабатывался язык и его синтаксис, тогда как в С++ все с точностью наоборот. Сперва сделали С с классами для реализации ограниченного набора идей, а уже после начали на него наворачивать новые концепции, пытаясь их встроить в уже существующий синтаксис.
Как по мне, так самое глупое, что может сделать программист отдельного компонента (функции, метода или библиотеки), это завершать работу всего приложение, если не знает как обработать в данный момент ошибочную ситуацию.
Использование исключений обязано определяться требованиями, а никак не личными предпочтениями разработчика или его пониманием (или не пониманием) обработки данных.
Вам уже написал, что это вы ССЗБ и нечего пенять на молоток при кривых руках.
Я думаю, что он не загнется (ведь ассемблеры существуют до сих пор?). Просто в будущем он займет примерно такую же роль, как сейчас LLVM для генерации машинного кода. Супер универсальный высокоуровневый язык программирования без накладных расходов, но писать на нем вручную можно будет только либо отдельные небольшие фрагменты, либо полностью автоматически генерированный код.
У вас класс принимает бизнес данные в конструктор, а это особенный вызов, который физически не может вернуть информацию об ошибке никаким другим способом, кроме как вызвать исключение.
Делайте или статический фабричный метод или проверяйте данные не в конструкторе, а с помощью обычной функции. Другими словами, прерывания тут совершено не причем.
Данная фраза относится к архитектурным требованиям, которые я считаю разумными. Но вы можете использовать исключения в каких нибудь других вариантах использования. Ведь это обычный инструмент, и как его применять, только ваше дело.
Так именно это я и имею ввиду. Исключения нельзя использовать для обработки часто возникающих ситуаций. Их назначение - прерывать поток выполнения при возникновении не восстановимой ситуации, когда становится не важна производительность и требуется корректно обработать завершение приложения. Но если на более высоком уровне есть механизм обработки подобных ситуаций, то пусть он перехватывает исключения и продолжает работу приложения дальше (например вот так Избавляемся от ошибок Segmentation fault из-за переполнения стека в С++).
Другими словами, исключение, это не обработчик ошибок, а возникновение события достаточного для завершения работы всего приложения, но с возможностью его обработки на более высоких уровнях.
std::set_terminate ?
Вы не ответили на заданный вопрос.
К тому же у вас всегда остается возможность просто не перехватывайте исключения. Тогда приложение будет сразу завершаться, что будет полностью соответствовать поведению Rust.
Иииии…?
Я не требую использовать исключения в качестве единственного варианта обработки ошибок. Я пишу про то, что в определенных случаях исключения очень удобны, а прерывание выполнения потока команд так или иначе присутствует во всех языках программирования, даже в тех, у которых исключения якобы отсутствуют.
Поэтому лучше иметь стандартизированные исключения с возможностью их обработки в рантайме, чем в каждом случае завершать выполнение приложения по abort или с помощью хаков пытаться реализовывать перехват подобных ошибок.
И каждого варианта свои стандарты, свои компиляторы, возможно свои особенности синтаксиса … И все это должно иметь возможность взаимодействия между сбой. Как представлю, бррр… :-(