Не знаю как в c#, но в java в finaly можно получить исходное искоючение и что-то сделать (не перехватить но обработать).
Если у вас не так - то я не понимаю как try finaly решает проблему "нужно вывести ошибку в том ui компоненте, откуда пользователь кнопку нажал, а catch у нас где угодно но не там"
Я же написал - оклад ниже, но есть серъезный набор премий за выполнение плана. Т.е. если нигде не накосячил - выйдет примерно то-же на то-же, если результаты хорошие показал - то больше на 20 - 30%, если превосходные - может и кратно больше быть. Часть премиальных выдается долей в компании - акциями пример - чтобы руководитель имел шкурный интерес тащить компанию вперёд, часть выдаётся отложенно на 6 месяцев (теряешь при уходе) - чтобы не было мотивации сжечь все ресурсы сейчас, и сбежать с премиальными.
При этом я заметил, что по ходу работы - сами по себе находились сотрудники, которые больше любили управленческие задачи, и вот следующие 2 раза именно такие уходили в руководители, а технари (а т.ч. я) отказывались.
Видел случай, кого руководитель совмещал задачи исполнителя и всё было хорошо. Но то был хороший руководитель - у него руководство было приорететной задачей, а вот если все хорошо и осталось время, то подбивал какие-то мелкие, простые или не совсем кодинговые задачи.
А в статье про случай наоборот - когда руководитель ставит на первое место исполнительские задачи - такое видел, когда человек шел на повышение ради денег, а не смены направления.
У меня был превосходный руководитель 11 из 10 в первой компании где я работал (его любили сотрудники, отдел показывал превосходные результаты каждый год, все вопросы решались). Когда-то он был неплохим разработчиком, на уровне мидла (но в работе оказалось что административные и управленческие задачи он решает лучше, и его повысили), но даже если бы он был супер-разработчиком - в его обязанности 5 лет не входило написание когда, и за это время он настолько отстал от прогресса, что задачу сложнее уровня джуна делать не брался.
И тем не менее руководителем он от этого хуже не стал. В итоге когда его переманили в бОльшую компанию - отдел стал со временем понемногу разваливаться - золотые времена кончились.
Это как с хирургией и терапией - не нужно быть отличным терапевтом, чтобы быть отличным хирургом, но базовые знания и некоторое количество специализированных всё же важны.
Вообще, когда у руководителя оклад больше, чем у лучшего эксперта - это косяк компании.
В адекватных бизнесах - у руководителя оклад ниже чем топового линейного сотрудника, но есть значительное количество бонусов, за выполнение целей. (В том числе акций и долей). Причём это хорошо размазывают тонким слоем по времени (например половину сейчас, а половину через 6 месяцев, если продолжаешь работать) - чтобы руководитель думал в долгосрок - а не как получить максимум бонусов и сбежать.
Т.е. если совпадёт что 90 летний дед на коляске, проигнорировав шум и дребезг выгорающего двигателя (допустим он будет далекоо наврху, а старик глухой), будет очень медленно заезжать на платформу, и не среагирует на плавно тронувшийся вверх лифт (вообще с пассажиром балансировка лифта будет уже обратная - и он никуда не поедет, или будет ну ооооочень медленно ползти вверх), но типо он только вот начал заезжать, двигатель при этом тоже не содержит защиты, и будет свободно вращяться после выгорания. То да - есть вероятность негативных последствия.
Но это все равно не тянет на "лифт убийца". Вот видео где карусель в дубае пополам лопнула - это "карусель убийца". Или когда какая-то деталь в штатной эксплуатации гарантированно приводит к поломке - тоже.
Вообще на хабре лучше про политику не писать. И ресурс непрофильный, и любая высказанная позиция всё равно неправильная будет.
Я вот тоже не удержался, соблазнился на ваш комментарий, который ну совсем как та реклама - "для вечной молости и лечения рака, нужен простой советский...". Хотя не нужно было.
А куда интереснее было бы почитать в комментарях аргументы от системных администраторов в духе того - насколько сервера потенциальной компании разведчика - могут собрать ценную информацию, будучи установлены у операторов, и как сложно будет её получить без них.
Тут например пишут про всякие traceroute - но как будто для составления карты операторских стыков - никакого инструментария не хватит.
Вот люди из Мурманска не могли. И это даже без отключения мобильной сети.
Ну то есть - проблема в том, что из за отключения интернета для защиты от дронов, люди из мурманска не могли вызвать скорую помощь, до того как начали отключать интернет для защиты от дронов? Я все правильно понимаю?
Очень напоминает риторику, когда на решение любой проблемы - приплетают другую, и что мол пока все одновременно разом не решим - толку не будет. Ну т.е. если все поголовье слонов разом не съесть, то зачем стараться и не считается.
Например - вы говорите - "вот в японии ради одной девочки целый поезд оставили", а я отвечаю - "это скорее всего идиотизм, и так делать не надо, потому что на сумму, которую потратят на зарплаты машиниста и обслуживание этого поезда, соляру и обслужтвание станции - можно решить проблему девочки другим способом (да частного водителя будет в 10 раз дешевле нанять), а оставшиеся деньги потратить с пользой"
А такой "приплетающий" человек на это говорит - а смысл в этих деньгах, их всё равно разворуют.
Ну то есть решаем одну проблему, а есть ещё одна, значит и первую решать бессмысленно, а на вторую найдётся ещё третья - в сёлах воды нет например, значит опять, зачем первую решать без второй и третьей, и пятой десятой.
А то что в реальности все эти проблемы порциями и секторами решают по чуть чуть (операторы мобильной связи например уже тестируют варианты настройки сетей, где потоковое видео в случае замедления не пройдет, а вот трафик приложений вполне) - таким людям непонятно. Что и газ проводят от села к селу, и воду делают начиная с тех мест, где это принесёт максимум пользы.
Ну я так понял из коммента, что у вас скорее локальные перехватчики - вида try finaly - где finaly в том числе проверяет и обрабатывает exception. Это не про глобальную перехватку как раз, а в целом хороший подход.
Единый обработчик ошибок который я имел ввиду, это когда в условном singletone лежит switch(error) case на сотню вариантов, где на каждый вариант вызывается некоторый обработчик конкретной ошибки.
Логика может быть сложнее, чем освободить ресурсы - например в зависимости от ошибки - нужно освободить не все ресурсы, а только определённую часть. И тогда в finlay придется получать исходное исключение - и вот уже обработка ошибки размазана на две части а очевидность потеряна.
Или тоже самое - нужно перестроить ui c учетом ошибки. Для этого viewModel должна вернуть в View состояние ошибки, но оно уже было перехвачено на уровне единого обработчика - а значит либо он должен во viewModel передать данный (читай иметь ссылку), либо в finlay проверяем наличие exception на уровне viewModel - но у нас опять - половина ошибки в едином контроллере, а половина в viewModel слое. А если нам еще параметры передать из viewModel в логгер для ошибки надо например - вообще пиши пропало.
Ну предположим ситуация такая - мы открыли ресурс (например соединение с базой данных), а потом сделали запрос на сервер, пришел null в критически важном параметре (может он там по БЛ может быть null, может просто ошибка, не важно) - в случае чистого try - catch - ты заворачиваешь закрытие содениня с базой в finaly и знаешь - что не важно - ошибка там или успешное выполенние - соединение с базой не будет подвешено. А тут - случился nullpointer - но exception перехватился в едином обработчике исключений, а он вне контекста, который открыл соединение с базой (в нём нет ссылки на класс, который открыл содединение с базой). Это значит либо обработчик ошибок должен знать про класс, который инициировал запрос - а тогда он обо всём на свете будет знать - каша и связность, либо все должны ему свои обратные вызовы передавать для дополнительных действий при получении ошибки - а тогда это ничем не лучше, чем try catch по месту вызова запроса. И чтобы это работало - калбек должен прицепляться именно к запросу т.к. на разные запросы, даже в рамках одного контекста, могжет быть разная обработка одних и тех-же exception.
Буквально в прошлом проекте был такой, и показал себя ужасно.
Во первых такой класс, даже если он чисто управление передаёт - очень быстро растёт. Во вторых, он так-же быстро обрастает доп условиями - когда требуется контекст. Например пришел nullpointer - надо ресурсы освободит, значит надо как-то ошибку вернуть в точку вызова, или когда нужно добавить дополнительные данные для аналитики, но варианты этих данных разные. Или когда нужно логировать, но не все. Или когда разное количество retry надо сделать.
Вы вероятно скажете, что надо заводить отдельные ошибки под каждые данные - но это придет после, когда у вас уже заложена логика с развилками в зависимости от контекста, и даже если нет - приведёт к еще большому разрастанию этого большого единого обработчика. И не дай бог у вас будет цепочка наследования ошибок типо MyError : Retryable : NetworkError ... - потом когда поведение одного из обработчиков надо будет специализировать - все вообще развалится.
А ещё это усложняет вход в проект - намного менее очевидно - откуда пришла или куда пропала ошибка. Да - в теории в стак-трейсе все должно быть, но на практике были проблемы.
Короче на долгоживущих проектах я бы не рекомендовал такой подход.
Лучше либо локальные перехватчики для небольшого контекста (типо экрана) - там ошибку поймал - состояние экрана в нужное привёл, ретраи в нужном порядке и тайминге сделал и молодец. А если нужно, через композицию подключил какой-то из общих обработчиков, и параметризовал.
Либо result использовать там, где ошибка внутри нашей бл. Он не так красив но намного более очевиден.
Ваш совет хорош, но сработает только в идеальном мире - где геополитика стран направлена на мирное сосуществование и сотрудиничество. Но в реальном мире - геополитика, это как заходить в бой в quake на сервере - где все противники играют с читами. Ты либо умираешь, либо пробуешь парировать их читы своими.
А читы у всех разные - те, кто по везучее ядерными бомбами звенят, одновременно запрещая другим их иметь, у кого-то профессиональные навыки в цветных революциях, кто-то с рынком углеводородов картельных сговор устраивает, а кто-то межбанковским ппреводам угрожает.
Не нравится тебе - что у соседа скоро мирные аэс появятся - обвинил в чём нибудь, и отправил бомбардировщики, почему бы и нет. Вот и нет конкурентов в инергетике.
Потому что вызвать скорую я могу - отключают только интернет - звонки и смс работают. По крайне мере в 2х регионах где я застал отключения. А про воду - демагогия, это примерно как сказать "а почему люди болеют". Ну в каких-то сёлах наверное нет воды, где-то она и не нужна (у всех скважины), где-то село вымирает - и уже нет смысла, где-то нет муниципальных средств - когда место глубоко убыточное.
Вы верно в войсках рэб сидите и к засекречееной информации об эфективности перехвата дронов доступ имеете?
Я вот общался по поводу отключения интернета - зачем и почему - с человеком, который по должности с этими дронами работает - только с нашими.
Так вот, сейчас делают так - дрон запускается у черта на рогах, и летит от туда по gps + инерционная навигация, а на подлете к точке - подключается к сети и превращается в fpv для точного попадания.
В мост например еще реально попасть по gps, и то не факт, нужно не ошибиться с высотой, и попасть правильно, иначе не рухнет. На военных объектах имеет место ротация - там штуки которые надо сохранить и можно подвинуть - двигают.
Без интернета дрон fpv не станет, gps можно подавить и спокойно увести его за город, где мягко "призмелить".
Ну и вконце концов не за весь контент идут деньги - есть ещё такой, за который не платят, но он опасен - вы вот хотели бы, чтобы гопнички с вашего района - могли свободно нагуглить, как бытовой химии взрывчатку делать? А любой учитель химии вам подтвердит, что бомбу с небольшим радиусом поражения сделать дома не особо сложно.
Мошенники в другой юрисдикции а деньги получают через крипту или дропов. Приезжает друг из ближнего зарубежья, делает карту в местном банке, а потом выезжает к себе на родину - далее переводы идут ему (а если бизнес "серъезный", то даже с отмывкой) и он их той-же "золотой короной" выводит на свою карту. А когда дело дойдет до суда/туда - у него уже новые документы будут. (Нет серьезно, у меня одного товарища из таджикистана - 3 раза из россии депортировали, он делал новый паспорт и въезжал, и вроде даже фамилия там другая каждый раз - говорил это не особо сложно)
А про крипту, так ежили крипту запретить - вы же первый придете писать в комменты что правительство опять лезет туда, куда не надо.
Я согласен с вами, хорошего в этом ничего нет. Но предложите решение лучше?
Вот есть сайт, который делает что-то нехорошее (детские неподобающие видео продает, оружие, казино, мошенничество etc) - как с ним бороться - если тебе на блокировку 2 месяца надо, а им на переезд 2 часа, и у них - "а что ты мне сделаешь, я в другом городе"
Не знаю как в c#, но в java в finaly можно получить исходное искоючение и что-то сделать (не перехватить но обработать).
Если у вас не так - то я не понимаю как try finaly решает проблему "нужно вывести ошибку в том ui компоненте, откуда пользователь кнопку нажал, а catch у нас где угодно но не там"
Да, и ответсвенность должна иметь денежный вес - по этому окдад меньше, но большая мотивирующая составляющая.
Просрал все зоны ответсвенности - остался с окладом ниже разработческой.
Я же написал - оклад ниже, но есть серъезный набор премий за выполнение плана. Т.е. если нигде не накосячил - выйдет примерно то-же на то-же, если результаты хорошие показал - то больше на 20 - 30%, если превосходные - может и кратно больше быть. Часть премиальных выдается долей в компании - акциями пример - чтобы руководитель имел шкурный интерес тащить компанию вперёд, часть выдаётся отложенно на 6 месяцев (теряешь при уходе) - чтобы не было мотивации сжечь все ресурсы сейчас, и сбежать с премиальными.
При этом я заметил, что по ходу работы - сами по себе находились сотрудники, которые больше любили управленческие задачи, и вот следующие 2 раза именно такие уходили в руководители, а технари (а т.ч. я) отказывались.
Видел случай, кого руководитель совмещал задачи исполнителя и всё было хорошо. Но то был хороший руководитель - у него руководство было приорететной задачей, а вот если все хорошо и осталось время, то подбивал какие-то мелкие, простые или не совсем кодинговые задачи.
А в статье про случай наоборот - когда руководитель ставит на первое место исполнительские задачи - такое видел, когда человек шел на повышение ради денег, а не смены направления.
У меня был превосходный руководитель 11 из 10 в первой компании где я работал (его любили сотрудники, отдел показывал превосходные результаты каждый год, все вопросы решались). Когда-то он был неплохим разработчиком, на уровне мидла (но в работе оказалось что административные и управленческие задачи он решает лучше, и его повысили), но даже если бы он был супер-разработчиком - в его обязанности 5 лет не входило написание когда, и за это время он настолько отстал от прогресса, что задачу сложнее уровня джуна делать не брался.
И тем не менее руководителем он от этого хуже не стал. В итоге когда его переманили в бОльшую компанию - отдел стал со временем понемногу разваливаться - золотые времена кончились.
Это как с хирургией и терапией - не нужно быть отличным терапевтом, чтобы быть отличным хирургом, но базовые знания и некоторое количество специализированных всё же важны.
Вообще, когда у руководителя оклад больше, чем у лучшего эксперта - это косяк компании.
В адекватных бизнесах - у руководителя оклад ниже чем топового линейного сотрудника, но есть значительное количество бонусов, за выполнение целей. (В том числе акций и долей). Причём это хорошо размазывают тонким слоем по времени (например половину сейчас, а половину через 6 месяцев, если продолжаешь работать) - чтобы руководитель думал в долгосрок - а не как получить максимум бонусов и сбежать.
Ну кое как натянули.
Т.е. если совпадёт что 90 летний дед на коляске, проигнорировав шум и дребезг выгорающего двигателя (допустим он будет далекоо наврху, а старик глухой), будет очень медленно заезжать на платформу, и не среагирует на плавно тронувшийся вверх лифт (вообще с пассажиром балансировка лифта будет уже обратная - и он никуда не поедет, или будет ну ооооочень медленно ползти вверх), но типо он только вот начал заезжать, двигатель при этом тоже не содержит защиты, и будет свободно вращяться после выгорания. То да - есть вероятность негативных последствия.
Но это все равно не тянет на "лифт убийца". Вот видео где карусель в дубае пополам лопнула - это "карусель убийца". Или когда какая-то деталь в штатной эксплуатации гарантированно приводит к поломке - тоже.
А тут - ну максимум "лифт который может убить"
Вообще на хабре лучше про политику не писать. И ресурс непрофильный, и любая высказанная позиция всё равно неправильная будет.
Я вот тоже не удержался, соблазнился на ваш комментарий, который ну совсем как та реклама - "для вечной молости и лечения рака, нужен простой советский...". Хотя не нужно было.
А куда интереснее было бы почитать в комментарях аргументы от системных администраторов в духе того - насколько сервера потенциальной компании разведчика - могут собрать ценную информацию, будучи установлены у операторов, и как сложно будет её получить без них.
Тут например пишут про всякие traceroute - но как будто для составления карты операторских стыков - никакого инструментария не хватит.
Ну то есть - проблема в том, что из за отключения интернета для защиты от дронов, люди из мурманска не могли вызвать скорую помощь, до того как начали отключать интернет для защиты от дронов? Я все правильно понимаю?
Очень напоминает риторику, когда на решение любой проблемы - приплетают другую, и что мол пока все одновременно разом не решим - толку не будет. Ну т.е. если все поголовье слонов разом не съесть, то зачем стараться и не считается.
Например - вы говорите - "вот в японии ради одной девочки целый поезд оставили", а я отвечаю - "это скорее всего идиотизм, и так делать не надо, потому что на сумму, которую потратят на зарплаты машиниста и обслуживание этого поезда, соляру и обслужтвание станции - можно решить проблему девочки другим способом (да частного водителя будет в 10 раз дешевле нанять), а оставшиеся деньги потратить с пользой"
А такой "приплетающий" человек на это говорит - а смысл в этих деньгах, их всё равно разворуют.
Ну то есть решаем одну проблему, а есть ещё одна, значит и первую решать бессмысленно, а на вторую найдётся ещё третья - в сёлах воды нет например, значит опять, зачем первую решать без второй и третьей, и пятой десятой.
А то что в реальности все эти проблемы порциями и секторами решают по чуть чуть (операторы мобильной связи например уже тестируют варианты настройки сетей, где потоковое видео в случае замедления не пройдет, а вот трафик приложений вполне) - таким людям непонятно. Что и газ проводят от села к селу, и воду делают начиная с тех мест, где это принесёт максимум пользы.
Ну я так понял из коммента, что у вас скорее локальные перехватчики - вида try finaly - где finaly в том числе проверяет и обрабатывает exception. Это не про глобальную перехватку как раз, а в целом хороший подход.
Единый обработчик ошибок который я имел ввиду, это когда в условном singletone лежит switch(error) case на сотню вариантов, где на каждый вариант вызывается некоторый обработчик конкретной ошибки.
Логика может быть сложнее, чем освободить ресурсы - например в зависимости от ошибки - нужно освободить не все ресурсы, а только определённую часть. И тогда в finlay придется получать исходное исключение - и вот уже обработка ошибки размазана на две части а очевидность потеряна.
Или тоже самое - нужно перестроить ui c учетом ошибки. Для этого viewModel должна вернуть в View состояние ошибки, но оно уже было перехвачено на уровне единого обработчика - а значит либо он должен во viewModel передать данный (читай иметь ссылку), либо в finlay проверяем наличие exception на уровне viewModel - но у нас опять - половина ошибки в едином контроллере, а половина в viewModel слое. А если нам еще параметры передать из viewModel в логгер для ошибки надо например - вообще пиши пропало.
Ну предположим ситуация такая - мы открыли ресурс (например соединение с базой данных), а потом сделали запрос на сервер, пришел null в критически важном параметре (может он там по БЛ может быть null, может просто ошибка, не важно) - в случае чистого try - catch - ты заворачиваешь закрытие содениня с базой в finaly и знаешь - что не важно - ошибка там или успешное выполенние - соединение с базой не будет подвешено. А тут - случился nullpointer - но exception перехватился в едином обработчике исключений, а он вне контекста, который открыл соединение с базой (в нём нет ссылки на класс, который открыл содединение с базой). Это значит либо обработчик ошибок должен знать про класс, который инициировал запрос - а тогда он обо всём на свете будет знать - каша и связность, либо все должны ему свои обратные вызовы передавать для дополнительных действий при получении ошибки - а тогда это ничем не лучше, чем try catch по месту вызова запроса. И чтобы это работало - калбек должен прицепляться именно к запросу т.к. на разные запросы, даже в рамках одного контекста, могжет быть разная обработка одних и тех-же exception.
Вот я со всем с вами соглаен, кроме
Буквально в прошлом проекте был такой, и показал себя ужасно.
Во первых такой класс, даже если он чисто управление передаёт - очень быстро растёт. Во вторых, он так-же быстро обрастает доп условиями - когда требуется контекст. Например пришел nullpointer - надо ресурсы освободит, значит надо как-то ошибку вернуть в точку вызова, или когда нужно добавить дополнительные данные для аналитики, но варианты этих данных разные. Или когда нужно логировать, но не все. Или когда разное количество retry надо сделать.
Вы вероятно скажете, что надо заводить отдельные ошибки под каждые данные - но это придет после, когда у вас уже заложена логика с развилками в зависимости от контекста, и даже если нет - приведёт к еще большому разрастанию этого большого единого обработчика. И не дай бог у вас будет цепочка наследования ошибок типо MyError : Retryable : NetworkError ... - потом когда поведение одного из обработчиков надо будет специализировать - все вообще развалится.
А ещё это усложняет вход в проект - намного менее очевидно - откуда пришла или куда пропала ошибка. Да - в теории в стак-трейсе все должно быть, но на практике были проблемы.
Короче на долгоживущих проектах я бы не рекомендовал такой подход.
Лучше либо локальные перехватчики для небольшого контекста (типо экрана) - там ошибку поймал - состояние экрана в нужное привёл, ретраи в нужном порядке и тайминге сделал и молодец. А если нужно, через композицию подключил какой-то из общих обработчиков, и параметризовал.
Либо result использовать там, где ошибка внутри нашей бл. Он не так красив но намного более очевиден.
Ваш совет хорош, но сработает только в идеальном мире - где геополитика стран направлена на мирное сосуществование и сотрудиничество. Но в реальном мире - геополитика, это как заходить в бой в quake на сервере - где все противники играют с читами. Ты либо умираешь, либо пробуешь парировать их читы своими.
А читы у всех разные - те, кто по везучее ядерными бомбами звенят, одновременно запрещая другим их иметь, у кого-то профессиональные навыки в цветных революциях, кто-то с рынком углеводородов картельных сговор устраивает, а кто-то межбанковским ппреводам угрожает.
Не нравится тебе - что у соседа скоро мирные аэс появятся - обвинил в чём нибудь, и отправил бомбардировщики, почему бы и нет. Вот и нет конкурентов в инергетике.
Потому что вызвать скорую я могу - отключают только интернет - звонки и смс работают. По крайне мере в 2х регионах где я застал отключения. А про воду - демагогия, это примерно как сказать "а почему люди болеют". Ну в каких-то сёлах наверное нет воды, где-то она и не нужна (у всех скважины), где-то село вымирает - и уже нет смысла, где-то нет муниципальных средств - когда место глубоко убыточное.
Нижн описал причём тут интернет
Вы верно в войсках рэб сидите и к засекречееной информации об эфективности перехвата дронов доступ имеете?
Я вот общался по поводу отключения интернета - зачем и почему - с человеком, который по должности с этими дронами работает - только с нашими.
Так вот, сейчас делают так - дрон запускается у черта на рогах, и летит от туда по gps + инерционная навигация, а на подлете к точке - подключается к сети и превращается в fpv для точного попадания.
В мост например еще реально попасть по gps, и то не факт, нужно не ошибиться с высотой, и попасть правильно, иначе не рухнет. На военных объектах имеет место ротация - там штуки которые надо сохранить и можно подвинуть - двигают.
Без интернета дрон fpv не станет, gps можно подавить и спокойно увести его за город, где мягко "призмелить".
Ну и вконце концов не за весь контент идут деньги - есть ещё такой, за который не платят, но он опасен - вы вот хотели бы, чтобы гопнички с вашего района - могли свободно нагуглить, как бытовой химии взрывчатку делать? А любой учитель химии вам подтвердит, что бомбу с небольшим радиусом поражения сделать дома не особо сложно.
Мошенники в другой юрисдикции а деньги получают через крипту или дропов. Приезжает друг из ближнего зарубежья, делает карту в местном банке, а потом выезжает к себе на родину - далее переводы идут ему (а если бизнес "серъезный", то даже с отмывкой) и он их той-же "золотой короной" выводит на свою карту. А когда дело дойдет до суда/туда - у него уже новые документы будут. (Нет серьезно, у меня одного товарища из таджикистана - 3 раза из россии депортировали, он делал новый паспорт и въезжал, и вроде даже фамилия там другая каждый раз - говорил это не особо сложно)
А про крипту, так ежили крипту запретить - вы же первый придете писать в комменты что правительство опять лезет туда, куда не надо.
Я согласен с вами, хорошего в этом ничего нет. Но предложите решение лучше?
Вот есть сайт, который делает что-то нехорошее (детские неподобающие видео продает, оружие, казино, мошенничество etc) - как с ним бороться - если тебе на блокировку 2 месяца надо, а им на переезд 2 часа, и у них - "а что ты мне сделаешь, я в другом городе"